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(57) Abstract 



The invention concerns a device and a method for control- 
ling a portable object life cycle, in particular a smart card (1), the 
life cycle being determined by successive of state transitions, said 
states determining the services offered by the object, said object 
comprising a processing unit (2), programme storage units (4) and 
data storage units (5), each of said storage unit having a content 
defining a plurality of configurations. The device is characterised 
in that it comprises means controlling (9, 11, 12) the transition 
from one first state to a second state of said object and, preferably 
means for triggering actions when the transition crossover from 
one state to another occurs or when such a transition crossover 
request is ckvticd. The method is characterised in that it comprises 
a plurality of steps dependent on the type of transitions implied in 
the request for state transition crossover applied to the object. 
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L 1 invention conceme un dispositif et un proc&ie* de contrdle 
du cycle de vie d'un objet 61ectronique portatif, notamment une 
carte a puce (1), le cycle de vie €tant d6termin6 par une succession 
de transitions d'6tats, lesdits 6tats determinant les services offerts 
par r objet, Iedit objet comprenant une unite* de traitement (2), des 
mdmoires de programmes (4) et des m6moires de donn6es (5), 
chacune de ces m6moires pr6sentant un contenu d^finissant une 
pluralitd de configurations. Le dispositif est caracterise* en cequ'il 
comprend des moyens de contrdle (9, 1 1, 12) de la transition d'un 
premier 6 m a un second 6tat dudit objet et, preT£rentieIlement des moyens permettant de ddclencher des actions lors du franchissement 
ou du rejet du franchissement de la transition d^tat demandee. Le proc£d6 est caract£rise* en ce qu'il comprend une pluralitd d'dtapes 
dfpendantes du type des 6tats impliqu6s dans la demande de franchissement de transition d'etat appliquee a Tobjet. 
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2„ MICROPROCESSOR 
3_. VOLATILE MEMORY (RAM) 
4„ PROGRAMME MEMORY (ROM) 
7._ PROGRAMMES (OR OPERATING 

SYSTEMS) 
9... VERIFICATION DRIVE 
10... PRE-DEFINEO DATA 
11.16... TRANSITION TABLE 



12.17_. VERIFICATION TABLE 
13.18™ ACTION TABLE 

S„ DATA STORAGE (EEPROM) 
19... APPLICATION PROGRAMMES 
14- APPLICATION DATA 
9„. CURRENT STATE 
15... TABLE EXTENSION 
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PROCEDE ET DISPOSITIF DE CONTROLE DU CYCLE 
DE VIE D ! UN OB JET PORTATIF, NOTAMMENT D 1 UNE 

CARTE A PUCE 



L' invention concerne les objets eiectroniques portatifs 
tels que les cartes a microcircuits eiectroniques, dites 
cartes a puce qui, connectees a des dispositifs 
eiectroniques pour permettre a ces derniers de realiser des 
5 fonctions particulieres dans le cadre d'une ou plusieurs 
applications, necessitent un controle de leurs etapes de 
vie. Lesdites cartes sont en effet generalement utilisees 
dans des applications (banque, communication, identite, 
sante...) necessitant une grande securite contre les usages 
10 frauduleux. L • invention s ' applique plus generalement a tout 
systeme embarque independant, dote d'une unite de 
traitement et des memoires de programme et de donnees. 

II est connu dans le monde de la carte a puce que 
15 celle-ci resulte d'un assemblage d'un composant (comprenant 
en general un microprocesseur en relation avec des memoires 
via des bus de communication), d'un module (realise a 
l'aide d'un metal conducteur) auquel est relie ledit 
composant (dans le cadre d'une carte a puce dite a contact) 
20 pour permettre audit, composant d'etre connecte a un 
dispositif electronique de lecture et/ou ecriture (ou 
coupleur) ez d'un corps de carte ou plus generalement d'un 
support sur lequel est integre 1' ensemble modul e/ compos ant . 
Dans la cadre d'une carte a puce dite sans contact, ledit 
25 module est remplace par une antenne et 1' ensemble forme par 
le composanc et ladite antenne est integre au sein dudit 
support . 

La vie d'une carte a puce se decompose generalement en 
deux ensembles d* etapes se succedanc les unes aux autres, 
30 corresponda" respect ivement a la fabrication et a 
1 ' exploitation de ladite carte. La composition des deux 
ensembles d' etapes forme un cycle de vie de ladite carte. 
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La fabrication d'une carte a puce (a contact ou sans 
contact) est constitute de plusieurs etapes. 

En effet, il est tout d'abord necessaire de disposer 
d'un composant electronique qui est initialise, isole, puis 
5 reiie a un module. Ledit composant et le module, auquel il 
est relie, sont par la suite integres sur ou au sein d'un 
support (generalement un corps de carte plastique) lui meme 
imprime a des fins d * identification ou de publicite. Par la 
suite la carte a puce ainsi obtenue est initialisee ou 

10 programmee pour repondre aux conditions d 1 utilisation dans 
le cadre d ' applications . 

Le second ensemble d 1 etapes de vie d'une carte a puce 
correspond a son exploitation. Cet ensemble peut lui -meme 
etre divise en plusieurs etapes, chacune correspondant , par 

15 exemple, a 1 ' implantation ou la suppression de services 
offerts par la carte a puce a 1 ' utilisateur en fonction de 
son profil par exemple. 

En outre different s acteurs (fabricant de composant, 
fabricant de cartes a puce, centre de personnalisation de 

20 cartes, emetteur de cartes, ou encore porteur de cartes) 
interviennent durant les differentes etapes de la 
fabrication et de 1 ' exploitation d 1 une carte a puce. Ainsi, 
les composants sont fournis et parfois en partie 
initialises par des fabricants de composants electroniques 

25 sur une tranche de silicium. Cette phase correspond a 
I'etape de fabrication du composant. L'etape suivante est 
la phase d'encartage realisee par le fabricant de carte a 
puce. Elle inclut 1 ' isolement d'un composant de la tranche 
de silicium, la connexion dudit composant a un module (ou 

30 antenne) , 1 ' integration de 1 'ensemble sur leur support ou 
corps de carte. Suit la preparation de la structure 
applicative presence dans la memoire programmable 
elec"riquement du composant. C'est I'etape de 
personnalisation electrique qui est realisee par le 

3 5 fabricant des cartes . a puce ou par un centre de 
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personnalisation ou un tiers specialise dans la 
personnalisation des cartes ou par I'emetteur lui-meme qui 
est charge in fine de la distribution des cartes sur le 
marche . Cette phase de personnalisation electrique peut 
5 done etre decomposee en autant d' etapes qu'il y a acteurs 
ou d ' intermediates . Par la suite, durant 1 1 exploitation de 
la carte a puce, nous avons vu precedemment qu'il peut etre 
interessant de distinguer differentes etapes au gre de 
1* evolution du profil de 1 ' utilisateur de la carte par 
10 exemple. 

Quoi qu'il en soit, il est done important de suivre 
rigoureusement les etapes de vie d'une carte pour connaitre 
a tout moment l'etape en-cours de ladite carte au sein de 
son cycle de vie. De plus, il est indispensable que, d'une 

15 part, 1 ' acces en ecriture ou en lecture de la memoire 
programmable electriquement du composant d'une carte soit 
protege durant l'echange de ladite carte (ou du composant) 
entre les differents acteurs et que d' autre part 1' acces a 
ladite memoire soit limite au fur et a mesure que se 

20 succedent les etapes de vie de la carte citees 
precedemment, en activant ou desactivant des services par 
exemple. Pour finir, il est egalement necessaire parfois de 
valider le contexte applicatif de la carte a puce avant que 
le porteur de celle-ci 1' utilise sur le marche. Par 

25 exemple, un emetteur de carte a puce de type porte-monnaie 
electronique , doit etre certain que la balance de ladite 
carte est bien nulle avant d'emettre la carte. 

Pour tenter de repondre a ces exigences, differentes 
30 solutions sont utilisees a ce jour. Certaines solutions 
sont purement exterieures a la carte a puce ( securisation 
physique des locaux ou ladite carte est fabriquee, 
utilisation ae moyens de transport eux-memes securises. , . ) . 
D'autres solutions complementaires aux premieres, mais 
35 cette fois internes cu implantees dans la carte, sont aussi 
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generalement utilisees. On utilise ainsi des secrets 
permettant de proteger 1 ' acces en lecture/ecriture de la 
memoire du composant et egalement des indicateurs logiques 
permettant de suivre de maniere irreversible les 
5 differentes etapes de vie de la carte. Pour cela, des bits 
au sein d'une memoire non eff arable du composant de la 
carte a puce sont positionnes a l'etat actif a la fin des 
differentes etapes de vie de la carte (fabrication et 
initialisation du composant par le , f abricant dudit 

10 composant, encartage et initialisation de la memoire de la 
carte par le f abricant de carte a puce, preparation de la 
structure applicative de la memoire de la carte a puce par 
le centre de personnalisation ou l'emetteur de la 
carte...). En fonction de ces indicateurs, le programme (ou 

15 systeme d 1 exploitation) , execute par le microprocesseur du 
composant de la carte a puce f implante au sein de l'une des 
memoires dudit composant de ladite carte, adapte son 
comportement au fur et a mesure que les etapes de vie de 
ladite carte se succedent . Ainsi, des fonctions peuvent 

2 0 etre modifiees, ajoutees ou supprimees. 

Quelles que soient les solutions utilisees a ce jour, 
elles reposent toutes sur le fait que les differents 
acteurs impliques dans la fabrication d'une carte sont des 

25 tiers de confiance. Seules des personnes, susceptibles 
d ' intercepter des composants ou des cartes durant leur 
transfert entre deux des differents acteurs, sont supposees 
"fraudeurs potent iels" et les solutions exposees 
precedemment permettent de s 1 en affranchir. L ' adaptation du 

30 systeme d 1 exploitation de la carte en fonction des 
indicateurs irreversibies apporte un plus non negligeable. 
Ainsi, si les fabricants de composants ou de cartes 
inscrivent des donnees systemes ou des secrets, l f emetteur 
de la carte ne pourra par exempie librement s* affranchir 

3 5 desdits secrets ou modifier lesdites donnees systeme. 
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Cependant, cette solution ne resout pas le probleme d'une 
initialisation frauduleuse de la carte ou d'une erreur 
malencontreuse durant ladice initialisation, effectuee par 
l'un des acteurs. 

5 

L ' invention propose de remedier aux inconvenients de 
l'etat actuel de la technique. En particulier, 1 ' invention 
consiste a doter le systeme d 1 exploitation d'une carte a 
puce de moyens logiciels permettant audit systeme 

10 d' exploitation de maitriser un changement irreversible 
d'etape de vie de ladite carte en fonction d'un ensemble de 
verifications du contenu des memoires de cette meme carte a 
puce. En outre 1' invention prevoit que lors d'un changement 
d'etape de vie, le systeme d " exploitation de la carte 

15 puisse deciencher automat iquement des actions permettant 
d' adapter les services offerts par ledit systeme 
d ' exploitation de ladite carte. 

A cet effet, 1' invention concerne un dispositif de 
20 controle du cycle de vie d'un objet electronique portatif, 
le cycle de vie etant constitue par une succession de 
transitions d' etats, iesdits etats determinant les services 
offerts par 1' objet, ledic objet comprenant une unite de 
rraitement, une memoire volatile, des memoires de 
25 programmes e: des memoires de donnees, chacune de ces 
memoires .presentant un contenu definissant une pluralite 
de configurations , caracterise en ce qu'il comporte des 
moyens de ccntrole de la transition' d'un premier etat a un 
second etat de 1' objet elecuronique portatif. 

30 

Selon d'autres caracceristiques du dispositif selon 
1 ' invention : 

- les moyens de controle comportent : 

- des moyens d' autorisation et/ou d' interdiction de 
35 transition d' etats a effectuer; 
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des moyens de verification du contenu de la 
memoire volatile, des memoires de donnees et des 
memoires de programme de 1 'objet electronique 
portatif en fonction de la transition d'etats a 
5 effectuer; 

des moyens permettant de declencher des actions 
lors du traitement d'une demande de f ranchissement 
d'une transition d'etat. 

10 En outre, 1' invention concerne un objet electronique 

portatif, pouvant etre notamment une carte a puce, 
comport ant ledit dispositif de controle du cycle de vie. 

Par ailleurs, 1' invention concerne un procede de 
controle du cycle de vie d'un objet electronique portatif, 
ledit procede etant mis en oeuvre au sein de 1' objet a la 
suite d'une demande de transition d'etats, 
caracterise en qu'il comprend : 

- une etape de validation de 1 ' autorisation de ladite 
demande ; 

- une etape d 1 evaluation des verifications associee a 
la transition demandee; 

- une etape de modification de 1 1 etat courant de 
1' objet si et seulement si la transition demandee 
est autorisee et, si les verifications de la 
configuration de 1' objet sont satisfaites. 

Selon d'autres caracteristiques , le procede comprend 
eventuellement en outre : 
3 0 - une euape d ' execution d' actions systematiques ; 

une ecape d' execution d* actions positives dans le 
cas cu la transition demandee est autorisee et si 
les verifications associees a la transition demandee 
sont satisfaites; 



20 
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une etape d ' execution d' actions negatives dans le 
cas ou les verifications associees a la transition 
demandee he sont pas satisfaites. 

5 L ' invention sera mieux comprise a la lecture de la 

description qui suit et a 1 1 examen des figures qui 
1 ' accompagnent . Celles-ci ne sont donnees qu'a titre 
indicatif et nullement limitatif de 1' invention. 
Les figures montrent : 
10 - figure 1: un composant d'une carte a puce munie d'un 

dispositif de verification de transition d'etat; 
figures 2a et 2b: une representation detaillee d'une 
table des transitions d'etat; 

figure 3: une representation detaillee d'une table 
15 des verifications des transitions; 

figure 4: une representation detaillee d'une table 
des actions; 

figure 5: une description des etapes mises en ouvre 
dans le procede utilise par le dispositif de 
20 verification de transitions; 

figures 6a a 6d: les part icularites mises en oeuvre 
dans le cas d.'un exemple d'une carte a puce de type 
porte-monnaie electronique . 

25 Dans 1' invention, on appellera etat de reference, un 

etat a partir duquel il est possible de basculer vers un 
autre etat suite au f ranchissement d'une transition decrite 
dans la table des transitions, implantee dans la memoire de 
programme. Comme il est decrit plus loin, il est possible 

3 0 d' a j outer de nouveaux etats et done de nouvelles 
transitions apres que 1' etape de fabrication du composant 
aic eu lieu. Dans ce cas, on parlera d' etats additifs pour 
caracteriser ceux-ci par opposition aux etacs de reference. 
D 1 autre part, on appellera ecat courant 1 ' etat dans lequel 

2 5 se trouve le sysceme embarque . 
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La figure 1 montre un composant 1, d'une carte a puce, 
muni d'un dispositif de verification de transitions selon 
1' invention. Le composant comporte une unite de traitement 
5 2 ou encore microprocesseur en relation avec des memoires 
3, 4 et 5 via un bus de communication 6. Une memoire de 
programme 4 (ou encore ROM) non effagable comporte d'une 
part une zone de programmes 7, lesdits programmes (ou 
encore systeme d ' exploitation du systeme embarque) pouvant 

10 etre executes par ladite unite de traitement et d ' autre 
part une zone de donnees predefinies 10 qui contient des 
constantes utilisees par ledit systeme d ' exploitation. 
Parmi lesdites constantes de la zone 10, le systeme 
d ' exploitation 7, comportant un programme appele moteur de 

15 verification 9, exploite une table des transitions 11 qui 
permet de preciser les etats auxquels on peut acceder a 
partir de 1 ■ etat courant, une table des verifications 12 
qui permet d'associer a chaque transition d'etat des 
verifications portant sur le contenu des memoires 3, 4 

20 et/ou 5. Dans une variante, le moteur de verification 9 
peut declencher automat iquement des actions lors du 
f ranchissement ou du re jet du franchissement d'une 
transition. Pour cela la zone 10 de la memoire de programme 
comporte une table des actions 13 qui permet d'associer a 

25 chaque transition d'etat possible des actions a effectuer. 

Une memoire volatile 3 (ou encore RAN pour Random 
Access Memory en langue anglaise) permet a l'unite de 
traitement 2 de stocker de maniere temporaire des resultats 
ou encore des secrets issus de calculs decrits par les 

30 programmes implantes dans la memoire de programme 4. Le 
contenu de la memoire 3 est efface a chaque mise sous 
tension du composant 1 ou a chaque demande de remise a zero 
de celui -ci . 

Une memoire de donnees 5, effagable electriquement 
3 5 utilisant generalement . la technologie EE PROM (pour 
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Electrical Erasable Programmable Read Only Memory en langue 
anglaise) comporte une zone 14 contenant les connees 
variables necessaires a 1* execution des programmes 7. Cette 
zone 14 comporte notamment une donnee 8 appelee "Etat 
5 courant" permettant de memoriser l'etat courant de I'objet 
electronique portatif. La memoire de donnees 5 comporte en 
outre une zone 15 comprenant optionnellement des extensions 
des tables 11 a 13 dans le cas ou il est necessaire 
d* a j outer des etats aux etats de references. La zone 15 

10 comporte alors une extension de la table des transitions 
16, une extension de la table des verifications 17 et peut 
comporter une extension de la table des actions 18 si 1 ' on 
souhaite associer aux nouvelles transitons d'etat additif 
des actions, comme vu precedemment pour ce qui concerne la 

15 table 13. Dans le cas d'ajout d 1 etats par rapport aux etats 
de reference, il est parfois indispensable d'enrichir le 
systeme d 1 exploitation 7. Pour cela, la memoire 5 peut 
comporter en outre une zone 19 qui contient les programmes 
supplementaires qui seront executes a leur tour par 1' unite 

2 0 de traitement 2. 

La figure 2a montre une mise en ouvre possible de la 
table des transitions 11. Si 1 ' on suppose que 1 1 on denombre 
i etats de reference, on peut imaginer une table .de 

25 transition comprenant i colonnes et i lignes. Les colonnes 
correspondent aux etats de reference pouvant etre, a un 
instant donne, l'etat courant. Les i premieres lignes 
correspondent aux etats de reference auxquels on peut 
acceder a partir de l'etat courant. Ainsi la valeur d'une 

30 case de ia table des transitions 11 correspondant a 
1 1 intersection d'une ligne et d'une coionne de ladite table 
permet de coder soit, 1 ' absence de transition autorisee 
(valeur nulie par exempie - c'est le cas de la transition 
20), soit, 1 ' autorisation une transition (valeur non nulle 

35 - c'est le cas ce la transition 21) . Dans le cas d'une 
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transition autorisee, le moteur de verification de 
transitions recherche au sein de la table de verification 
12 les verifications a effectuer pour accepter ou rejeter 
le f ranchissement de la transition demandee . 

5 

La figure 2b montre egaiement une mise en ouvre 
possible d'une table de transition dans le cas ou il est 
possible d'ajouter des etats (etats additifs) aux etats de 
reference. La table des transitions comporte une ligne 

10 supplementaire par rapport a la figure 2a. La (i + l)eme 
ligne permet de preciser si 1 ' on autorise des transitions 
d'un etat de reference courant a un etat additif . Ainsi la 
valeur de la case 22 indique une transition interdite d'un 
etat de reference vers un etat additif. La case 23 indique 

15 qu'il sera possible de basculer de l'etat de reference Ei 
vers un etat additif. Une extension 16 de la table des 
transitions est alors necessaire. Cette derniere comporte j 
lignes correspondant a j etats additifs auxquels on peut 
acceder a partir de (i + j) etats courant possibles 

20 materialises par les (i + j) colonnes de 1' extension 16 de la 
table des transitions. Ainsi la combinaison de la case 23 
de la table des transitions et de la case 24 de 1' extension 
16 de la table des transitions, indique au moceur de 
verification qu f il est possible de basculer de l'etat de 

25 reference Ei vers l'etat additif E(i + 1). 

La figure 3 montre une mise en ouvre de la table des 
verifications. La table des verifications 12 est implantee 
au sein de la zone 10 des donnees predefinies de la memoire 

30 4. Chaque transition autorisee dispose d'une entree dans 
laditze table. Une entree comprend un champ 30 permettant 
d' identifier la transition et un champ 31 contenant une 
reference (ou adresse) vers un programme 32 du systeme 
d 1 exploitation 7. Le moteur de verification 9 peut ainsi 

35 faire executer a 1' unite de traitement 2 les controies 
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requis pour accepter le f ranchissement de la transition. La 
figure 3 illustre egalement une structure d'une extension 
17 de la table ' des verifications. De la meme maniere que 
pour la table 12, 1' extension de la table des verifications 
5 17 comporte une entree par transition possible. Chaque 
entree comprend deux champs, un champ 3 3 permettant 
d' identifier la transition et un champ 34 contenant une 
reference (ou adresse) d'un programme 35 du systeme 
d ' exploitation ou, comme le montre la figure 3, d'un 
10 programme supplementaire implant e dans la memoire de 
donnees 5 (en zone 19) . 

La figure 4 montre une representation de la table des 
actions 13 implantee dans la zone 10 des donnees 

15 predefinies de la memoire de programmes 4. Lors d'une 
demande de f ranchissement de transition, il est possible de 
declencher des actions. Celles-ci peuvent etre de trois 
types: action systematique, action positive (c'est a dire 
conditionnee au fait que les verifications sont 

20 satisf aisantes) ou action negative (c'est a dire 
conditionnee au fait que les verifications ne sont pas 
satisf aisantes) . La figure 4 montre qu ' a chaque transition 
autorisee, il existe une entree dans la table des actions 
13. Cette entree comprend 4 champs. Le premier champ 400 

25 permet d' identifier la transition. Les trois autres champs 
401, 402 et 403 contiennent chacun une reference ou adresse 
d'un programme 404, 405 ou 406 du systeme d ' exploitation . 
Le champ 4 01 esc dedie a une action systematique, le champ 
402 a une action positive et le champ 403 a une action 

3 0 negative. La figure 4 montre egalement une extension 18 de 
ia table des actions. Cette table 18 est implantee dans la 
zone 15 de la memoire de donnees 5 du ccmposant 1. De la 
meme maniere que pour la table des actions 13, 1 ' extension 
de la table des actions 18 comprend une entree par 

3 5 transition possible. Une entree comprend 4 champs. Le 
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premier champ 407 permet d ' identifier ia transition. Les 
trois autres champs 408, 409 et 410 contiennent chacun une 
reference ou adresse d'un programme 411, 412 ou 413 du 
systeme d 1 exploitation ou comme le montre la figure 4, des 
5 programmes implant es dans la zone 19 de la memoire de 
donnees 5 du composant 1. Le champ 408 est dedie a une 
action systematique , le champ 409 a une action positive et 
le champ 410 a une action negative. 

10 La figure 5a decrit le procede permettant de valider ou 

de rejeter le f ranchissement d'une transition d'etat, d'un 
premier etat de reference vers un autre etat de reference. 
La demande de f ranchissement d'une transition peut etre 
formulee suite a un ordre du fabricant de carte ou par tout 

15 autre acteur du cycle de vie de la carte a puce. Ladite 
demande peut egalement etre formulee directement par la 
carte-elle meme, par exemple au travers d'une action 
associee a une transition. Dans le cadre de la figure 5a, 
I 1 etat de reference courant est I'etat Ei. L' ordre 50 de 

20 bascuiement de I'etat Ei a I'etat Ej est formule. L'etape 
51 consiste a verifier au sein de la table des transitions 
11 que la transition de I'etat Ei vers I'etat Ej est 
autorisee. Dans le cas ou cette transition est interdite, 
la demande de f ranchissement de transition 50 est rejetee. 

25 L'etat courant demeure I'etat Ei . Par contre, si la 
transition est autorisee, le moteur de verification 9 
execute les verifications associees a ladite transition. 
Pour cela le moteur de verification evalue 1* entree de la 
table des verifications 12 dediee a la transition T(Ei- 

30 >Ej). L' execution desdites verifications correspond a 
l'etape 52 du procede. Le moteur de verification 9 execute 
les actions systematiques associees a la transition T (Ei - 
>Ej ) en fonction de 1 ' entree de la table des actions 13 
dediees a ladite transition (etape 53) . Si les 

3 5 verifications 54 exigees lors de la demande de 
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f ranchissement de la transition 50 sont non satisf aisantes, 
I'etat courant demeure inchange. En fonction de 1' entree de 
la table des actions 13 associee a la transition T (Ei- >Ej ) 
le moteur de * verifications execute les actions negatives 
5 (etape 55 du procede) . Le deroulement du procede est alors 
termine. Par centre, si les verifications 54 sont 
satisf aisante, alors I'etat courant devient I'etat Ej 
(etape 56 du procede) . Les actions positives sont alors 
executees (etape 57 du procede) en fonction de I'etat de 
10 1* entree de la table des actions 13 associee a la 
Transition T (Ei - >E j ) . Le deroulement du procede est 
termine . 

La figure 5b decrit le procede permettant de valider ou 

15 de rejeter le f ranchissement d'une transition d'etat, d'un 
premier etac additif vers un autre etat additif. L'etat 
additif courant est l'etat Ei . L'ordre 510 de basculer de 
l'etat additif Ei a l'etat additif (ou de reference) Ej est 
formule. L' etape 511 du procede consiste a verifier au 

20 sein de 1' extension la table des transitions 16 que la 
transition de l'etat Ei a I'etat Ej est autorisee. Dans le 
cas ou cezze transition est interdite, la demande de 
f ranchissement de transition 510 est rejetee. L'etat 
courant demeure I'etat Ei . Par contre, si la transition est 

25 autorisee, le moteur de verification 9 execute les 
verifications associees a ladite transition. Pour cela, le 
moteur de verification evalue 1 ' entree de 1 ' extension de la 
cable des verifications 17 dediee a la transition T (Ei - 
>Ej ) . L ' execution desdites verifications constitue 1 ' etape 

30 512 du procede. Le moteur de verification 9 execute les 
actions syscematiques associees a la transition T(Ei->Ej) 
en fonction de 1' entree de 1' extension de la table des 
actions IS dediees a ladite transition (etape 513 du 
procede) . Si ia verification 514 exigee lors de la demande 

35 de f ranchissement de ia transition 510 est non 
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satisf aisante, I'etat courant demeure inchange. En fonction 
de 1' entree de I* extension de la table des actions 18 
associee a la transition T(Ei->Ej) / le moteur de 
verification 9 execute les actions negatives (etape 515 du 
5 procede) . Le deroulement du procede est alors termine. Par 
contre, si les verifications 514 sont satisf aisantes , 
I'etat courant devient I'etat Ej (etape 516 du procede). 
Les actions positives sont alors executees (etape 517 du 
procede) en fonction de l'etat de 1' entree de 1 1 extension 
10 de la table des actions 18 associee a la transition T (Ei - 
>Ej ) . Le deroulement du procede est termine. 

La figure 5c decrit le procede permettant de valider ou 
de rejeter le f ranchissement d'une transition d'etat, d'un 
etat de reference vers un etat additif. L'etat de reference 
courant est l'etat Ei . L'ordre 520 de basculement de I'etat 
de reference Ei a l'etat additif Ej est f ormule . L' etape 
528 du procede consiste a verifier au sein de la table des 
transitions 11, qu'une transition de l'etat de reference 
courant Ei vers un etat additif est autorisee. Si une telle 
transition est interdite, le procede est termine. L'etat 
courant demeure inchange. Par contre, si une transition 
dudit etat de reference vers un etat additif est autorisee, 
le moteur de verification deroule les etapes 521 a 527 du 
procede, respect ivement identiques aux etapes 511 a 517 
decrites en liaison avec la figure 5b. 

Un exemple d ■ application dans le domaine du Porte- 
mcnnaie electronique est presente en liaison avec les 
figures 6a a Gd. Ladite application permet de regler des 
achats a l'aide "d 1 argent electronique" stocke dans une 
carte a puce, au lieu de payer en numeraire. L'emploi d'une 
telle technique impose une gestion des cartes aussi 
securisee que celle qu'aurait impose l'emploi du numeraire. 
II faut par exemple eviter la creation de monnaie fictive. 
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La securite d'une carte a puce porte-monnaie eleccronique 
repose generalement sur cies cles stockees a I'interieur de 
ladite carte a puce permettant des transactions securisees 
en utilisant la cryptographie . Une telle carte dispose d'un 
5 systeme d ' exploitation off rant un jeu de commandes et de 
services permettant de crediter cu de debiter de 1' argent. 
Au debut du cycle de vie de la carte a puce porte-monnaie 
electronique, ladite carte a puce n'est pas initialisee. 
Elle ne contient aucune information. La figure 6a montre 
10 les etats de reference predefinis : 

- Etat El "carte vierge" (reference 80) : seules des 
commandes de test permettant de valider le comport ement de 
la memoire de donnees 5 sont disponibles (verification que 
les cases memoires de technologie EEPROM peuvent etre 

15 correctement ecrites et effacees) ; 

- Etat E2 "carte testee" (reference 82) : Les commandes 
de test ne sont plus disponibles. A leur tour des commandes 
dites generalement "commandes physiques" (permettant un 
acces en ecriture par un adressage physique independamment 

2 0 de toute structure logique de type fichier par exemple) 

sont disponibles. Elles permettent d' initialiser la carte 
(ecriture dans la zone 14 de la memoire de donnees des 
constituants logiques necessaires au f onctionnement de 
1 ' application c'est a dire fichiers, balances.,.); 
25 - Etat E3 "carte initialisee" (reference 84) : les 

commandes physiques ne sont plus disponibles. Des commandes 
logiques permettent de personnaliser la carte (ajout de 
nouvelles structures logiques et initialisation de donnees 
dans lesdiees structures) sont utilisables. En outre, un 

3 0 mecanisme de recouvrement est active de sorte que la carte 

a puce ne perde pas la coherence de ces donnees lors d'une 
mise hors zension de celle-ci durant 1' execution de 1 ' une 
desdiues commandes logiques. 
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- Etat E4 "carue personnaiisee" (reference 86) : les 
commandes logiques specif iques a 1 ' application Porte- 
monnaie electroriique (debit/credit) sont activees. 

Le jeu de commandes disponibles evolue en fonction de 
5 l'etape de vie dans laquelle se trouve la carte a puce. Des 
informations stockees en memoire de donnees permettent au 
systeme d' exploitation de connaitre l'etat dans lequel la 
carte a puce se trouve. La figure 6a montre en outre que 
dans le cadre d'une carte de type porte-monnaie 

10 electronique, toutes les transitions entre etats de 
reference doivent etre franchies successivement (de l'etat 
El a l'etat E4) et ce de maniere irreversible. Toute autre 
transition est interdite. Seule la possibility d f utiliser 
ulterieurement des etats additifs 88 est offerte. Cette 

15 transition possible est referencee 87. Le systeme 
d 'exploitation en fonction de l'etat courant n'autorise 
qu'un ensemble de commandes specif iques a chaque etat de 
reference . 

Les verifications et les actions a declencher lors du 
20 f ranchissement d'une transition sont decrites comme suit : 
Transition de l'etat El vers l'etat E2 (notee 
T(E1->E2) et referencee 81) : 

- Verification: aucune 

- Action systematique : 

25 effacement de la memoire de donnees pour 

evicer qu'un fraudeur y laisse des donnees 
interpretables par le systeme 

d' exploitation de la carte; 
Transition de l'etat E2 vers l'etat E3 (notee 

30 T(E2->E3) et referencee 83) : 

- Verification: 

integrite des donnees ecrites dans la 
memoire de donnees avec les commandes 
physiques (validation d'un code de 
3 5 redondanc.e par donnee) ; 
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verification de 1'etat vierge de la 
memoire en dehors desdites donnees ; 

- Action positive : 

- activation du mecanisme de recouvrement ; 

5 - Transition de 1'etat E3 vers 1'etat E4 (notee 

T(E3->E4) et referencee 85) : 

- Verification: 

- nullite de la balance du porte monnaie 
electronique 

10 - Action : aucune 

- Transition de 1'etat E4 vers un etat additif (notee 
T(E4->Sadd) et referencee 87) : 

- Verification : aucune 

- Action : aucune 

15 

Les figures 6b a 6d illustrent respectivement une 
realisation d'une table des transitions 11, d'une table des 
verifications 12 et d'une table d' actions 13, selon 
1' invention. La table des transitions 11 telle que decrite 

20 en liaison avec la figure 6b permet de n' autoriser que les 
transitions 81, 83, 85 et 87. Pour ceia seules les cases 60 
a 63 de iadice table contiennent une valeur non nulle . Les 
autres cases de la table des transitions contiennent une 
valeur nulle pour indiquer que toute autre transition est 

25 interdite. La table des verifications telle que presentee 
au travers de la figure 6c, permet d'associer les 
verifications a satisfaire pour autoriser le f ranchissement 
des transitions 81, 83, 85 et 87, iesdites transitions 
autorisees par la table des transitions 11 (figure 6b) . 

30 Ainsi 1 ' entree 64 de la table des verifications 12 comporte 
un champ 641 permettant d l identifier que ladite entree est: 
dediee a la transition 81. L 1 entree 64 comporte en oucre un 
champ 642 contenant une reference nulle pour indiquer 
qu* aucune verification n'est demandee pour autoriser le 

35 f ranchissemer.u de la transition 81. Dans une variante, la 
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transition 81 ne dispose d'aucune entree associee. Cette 
variante est illustree plus loin dans le cas de la table 
des actions. La table des verifications 12 comporte une 
entree 65 qui comprend respect ivement un champ 651 pour 
5 indiquer que 1 ' entree est associee a la transition 83 et un 
champ 652 contenant la reference d'un programme 67, 
implante dans la memoire de programmes, pour que le moteur 
de verification puisse effectuer les verifications decrites 
precedemment. De meme, la table des verifications 12 

10 comporte une entree 66 qui comprend respectivement un champ 
661 pour indiquer que l 1 entree est associee a la transition 
83 et un champ 662 contenant la reference d'un programme 
68, implante dans la memoire de programmes, pour que le 
moteur de verification puisse effectuer les verifications 

15 decrites precedemment. 

La figure 6d presente une realisation de la table des 
actions 13. Ladite table comporte une entree 71 qui 
comporte un champ 711 permettant d' indiquer que ladite 

20 entree est associee a la transition 81. La meme entree 71 
comporte un champ 712 contenant la reference d'un programme 
75, implante dans la memoire de programmes, afin que le 
moteur de verification puisse executer les actions 
systematiques associees a la transition 81. L 1 entree 71 

25 comporte en outre un champ 713 et un champ 714 contenant 
une reference nulle pour indiquer au moteur de verification 
qu'aucune action positive rii negative n'est associee au 
f ranchissement de la transition 81. De la meme maniere, la 
table des actions 13 comporte une seconde entree 72 

3 0 comprenant les champs 721 a 724 pour indiquer au moteur de 
verification que ladite entree est associee a la transition 
83, que le programme 74 est a executer comme action 
positive lcrs du f ranchissement de ladite transition et 
qu'aucune action systematique ou negative n'est a executer. 

35 L'absence d'entree, au . sein de la table des actions 13, 
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associee a la transition 85, indique qu'aucune action 
(systematique, positive ou negative) n'est a executer lors 
du f ranchissement ou du re jet du f ranchissement de ladite 
transition. 

5 

Grace au dispositif et au procede tels que decrits ci- 
dessus, le cycle de vie d'un objet electronique portatif 
est maitrise. Chaque transition d'etats est irreversible et 
les verifications faites lors de chaque demande de 

10 transitions garantissent une configuration memoire de 
1* objet coherente. En outre les actions systematiques, 
positives ou negatives permettent d' adapter le comportement 
dudit objet. Enfin, dans le cas ou il est prevu d'autoriser 
une ou plusieurs transitions d ! un ou plusieurs etats de 

15 reference vers un etat additif, le cycle de vie de l'objet 
peut etre facilement enrichi, par exemple apres que l 1 objet 
soit emis sur le marche, sans que le cycle de vie predefini 
(compose par une succession de transitions d ! etat de 
reference vers un autre etat de reference) puisse etre 

20 detourne. 

Tout risque de fraude durant 1 1 initialisation d'un 
objet electronique portatif ou d 1 erreur malencontreuse 
durant ladite initialisation est ecarte tout en conservant 
grande adaptability du controle du cycle de vie de 1* objet. 
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RE VEND I CAT I ONS 



1. Dispositif de controle du cycle de vie d'un objet 
electronique portatif, le cycle de vie etant determine par 
une succession de transitions d 1 etats, lesdits etats 
determinant les services offerts par l'objet, ledit objet 
comprenant une unite de traitement (2) , une memoire volatile 
(3), des memoires de programmes (4) et des memoires de 
donnees (5), chacune de ces memoires (3, 4, 5) presentant un 
contenu definissant une pluralite de configurations, 

caracterise en ce qu'il comporte des moyens de controle 
de la transition d'un premier etat a un second etat de 
l 1 objet electronique portatif. 

2. Dispositif selon la revendicat ion 1, caracterise en ce 
que les moyens de controle comportent des moyens 
d ' autorisation et/ou interdiction de transitions d'etat. 

3. Dispositif selon l'une quelconque des revendications 1 
ou 2, caracterise en ce que les moyens de controle 
comprennent des moyens de verification du contenu de la 
memoire volatile (3) , des memoires de donnees (5) et des 
memoires de programmes (4) de l f objet electronique portatif 
en fonction de la transition d' etats a effectuer. 

4. Dispositif selon l'une quelconque des revendications 1 
a 3, caracterise en ce que les moyens de controle 
comprennent : 

- une table (11) des transitions d'etat possibles; 

- une table (12) des verifications a effectuer par 
transition d'etat possible; 

- un moteur de verification (9) exploitant lesdites 
tables . 
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5. Dispositif selon 1 - une quelconque des revendi cat ions 1 
a 4, caracterise en ce que les moyens de controle comprennent 
en outre des moyens permettant de declencher des actions lors 
du traitement d'une demande de f ranchissement de transition 
d'un premier etat a un second etat de l'objet electronique 
portatif . 



6. Dispositif selon la revendication 5, caracterise en ce 
que les moyens permettant de declencher des actions lors du 
traitement d'une demande de f ranchissement de transition d'un 
premier etat a un second etat de l'objet electronique 
portatif, comprennent une table (13) d' actions exploitable 
par ledit moteur de verification (9) . 

7. Dispositif selon 1 • une quelconque des revendications 1 
a 6, caracterise en ce que les moyens de controle de la 
transition d'un premier etat a un second etat de l'objet 
electronique portatif comprennent en outre : 

- une extension (16) de la table (11) des transitions 
d'etat possibles; 

- une extension (17) de la table (12) des verifications a 
effectuer par transition d'etat possible ; 

et en ce que le moteur de verification (9) exploite 
lesdites extensions de tables (16, 17) . 

3. Dispositif selon 1 ' une quelconque des revendications 5 
a 7, caracterise en ce que les moyens permettant de 
declencher des actions lors du traitement d'une demande de 
f ranchissement de transition d'un premier etat a un second 
etat de l'objet electronique portatif, comprennent en outre 
une extension (18) de la table (13) d'actions exploitable par 
le moteur de verification (9) . 



WO 00/30030 



22 



PCT/FR99/02678 



9. Objet electronique portatif, comportant une unite de 
traitement (2), une memoire volatile (3), des memoires de 
programmes (4) et des memoires de donnees (5) , caracterise en 

5 ce qu'il comporte le dispositif de controle du cycle de vie 
de 1' objet, selon l'une des revendications 1 a 8. 

10. Carte a puce, comportant une unite de traitement (2), 
une memoire volatile (3), des memoires de programmes (4) et 

10 des memoires de donnees (5), caracterise en ce qu'elle 
comporte le dispositif de controle du cycle de vie de la 
carte, selon l ! une des revendications 1 a 8. 

11. Procede de controle du cycle de vie d'un objet 
15 electronique portatif, le cycle de vie etant determine par 

une succession de transitions d'etats, lesdits etats 
determinant les services offerts par 1' objet, ledit objet 
comprenant une unite de traitement (2) , une memoire volatile 
(3) , des memoires de programmes (4) et des memoires de 

2 0 donnees (5), chacune de ces memoires (3, 4, 5) present ant un 
contenu definissant une pluralite de configurations, 

ledit procede etant mis en oeuvre, au sein de 1' objet, a 
la suite d'une demande de transition d'etats, 
caracterise en qu'il comprend : 

25 - une etape (51, 511, 528, 521) de validation de 

1 ' autcrisation de ladite demande; 

- une etape (52, 512, 522) d' evaluation des verifications 
associee a la transition demandee; 

- une etape (57, 517, 527) de modification de 1'etat 
30 courant de I'objet si et seulement si la transition demandee 

est autorisee (51, 511, 528, 521) et, si les verifications de 
la configuration de I'objet sont satisfaites (54, 514, 524). 
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12. Procede selon la revendication 11, caracterise en ce 
qu'il comprend en outre une etape (53, 513, 523) d' execution 
d ' actions systematiques . 

5 13. Procede selon l'une quelconque des revendications 11 

ou 12 , caracterise en ce qu'il comprend en outre une etape 
(56, 516, 526) d' execution d' actions positives dans le cas ou 
la transition demandee est autorisee (51, 511, 528, 521) et 
si les verifications associees a la transition demandee sont 
10 satisfaites (54, 514, 524) . 

14. Procede selon l'une quelconque des revendications 11 
a 13, caracterise en ce qu'il comprend en outre une etape 
(55, 515, 525) d' execution d' actions negatives dans le cas ou 

15 les verifications associees a la transition demandee ne sont 
pas satisfaites (54, 514, 524). 

15. Procede selon l'une quelconque des revendications 11 
a 14, mis en oeuvre au sein de I'objet, a la suite d'une 

20 demande de transition d'un premier etat de reference vers un 
second etat de reference, caracterise en qu'il comprend : 

- une etape (51) de validation de 1 ' autorisat ion de 
ladite demande consistant a analyser la table (11) des 
transitions possibles; 

25 " une etape (52) devaluation des verifications associee 

a la transition demandee consistant a exploiter une entree 
(30) d'une table (12) des verifications; 

- une etape (57) de modification de l'etat courant de 
l'objet si et seulement si la transition demandee est 

30 autorisee (51) et, si les verifications de la configuration 
de l'objet sont satisfaites (54). 
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16. Procede selon la revendication 15, caracterise en ce 
qu'il comprend en outre une etape (53) d' execution d'actions 
systematiques consistant a exploiter une entree (400, 401, 

5 404), correspondant a la transition demandee, d'une table 
(13) d'actions. 

17. Procede selon I'une quelconque des revendicat ions 15 
ou 16 , caracterise en ce qu'il comprend en outre une etape 
(56) d' execution d'actions positives consistant a exploiter 
une entree (400, 402, 405), correspondant a la transition 
demandee, d'une table (13) d'actions, dans le cas ou la 
transition demandee est autorisee (51) et si les 
verifications associees a la transition demandee sont 
satisfaites (54) . 

18. Procede selon l'une quelconque des revendicat ions 15 
a 17, caracterise en ce qu'il comprend en outre une etape 
(55) d' execution d'actions negatives consistant a exploiter 

20 une entree (400, 403, 406), correspondant a la transition 
demandee, de la table (13) d'actions, dans le cas ou les 
verifications associees a la transition demandee ne sont pas 
satisfaites (54) . 

25 19 • Procede selon l'une quelconque des revendications 11 

a 14, ledit procede etant mis en oeuvre au sein de l'objet, a 
la suite d'une demande de transition d'un premier etat 
additif vers un second etat additif, caracterise en ce qu'il 
comprend : 

30 " une etape (511) de validation de 1 ' autorisat ion de 

ladite demande consistant a analyser une extension (16) de la 
table (11) des transitions possibles; 
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- une etape (512) devaluation des verifications associee 
a la transition demandee consistant a exploiter une entree 
(33) d'une extension (17) de la table (12) des verifications; 

- une etape (517) de modification de 1 ' etat courant de 
5 l ! objet si et seulement si la transition demandee est 

autorisee (511) et, si les verifications de la configuration 
de l'objet sont satisfaites (514). 

20. Procede selon la revindication 19, caracterise en ce 
10 qu'il comprend en outre une etape (513) d' execution d' actions 
systematiques en analysant une entree (407, 408, 411) , 
correspondant a la transition demandee, d'une extension (18) 
d'une table (13) d 1 act ions . 

15 21. Procede selon 1'une quelconque des revendications 19 

ou 20, caracterise en ce qu ! il comprend en outre une etape 
(516) d l execution d' actions positives en analysant une entree 
(407, 409, 412), correspondant a la transition demandee, 
d'une extension (18) d'une table (13) d' actions demandee si : 

20 - la transition demandee est autorisee (511) 

- et, si les verifications associees a la transition 
demandee sent satisfaites (514) . 

22. Procede selon l ! une quelconque des revendications 19 
25 a 21, caracterise en ce qu'il comprend en outre une etape 

(515) d 1 execution d' actions negatives en analysant une entree 
(407, 410, 413), correspondant a la transition demandee, 
d'une extension (18) d'une table (13) d' actions dans le cas 
ou les verifications associees a la transition demandee ne 
30 sont pas satisfaites (514) . 

23. Procede selon 1 * une quelconque des revendications 11 
a 14, ledit procede etant mis en oeuvre, au sein de l'objet, a 
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la suite d'une demande de transition d'un etat de reference 
vers un etat additif, caracterise en ce qu'il comprend : 

- une etape (528) de validation de 1 » autorisation de 
d'une transition dudit etat de reference vers un etat additif 
en analysant la table (11) des transitions possibles ; 

- une etape (521) de validation de 1 1 autorisation de 
d'une transition dudit etat de reference vers ledit etat 
additif en exploitant une extension (16) d'une table (11) des 
transitions possibles; 

- une etape (522) devaluation des verifications associee 
a la transition demandee en exploitant une entree (33) d f une 
extension (17) d'une table (12) des verifications; 

- une etape (527) de modification de l'etat courant de 
I'objet si et seulement si la transition demandee est 
autorisee (528, 521) et , si les verifications de la 
configuration de I'objet sont satisfaites (524). 

24. Precede selon la revendication 23, caracterise en ce 
qu'il comprend en outre une etape (523) d' execution d' actions 
systematiques en exploitant une entree (407, 408, 411), 
correspondant a la transition- demandee, d'une extension (18) 
d'une table (13) d' actions. 

25. Procede selon l'une quelconque des revendications 23 
25 ou 24, caracterise en ce qu'il comprend en outre une etape 

(5'2 6) d' execution d' actions positives en exploitant une 
entree (407, 409, 412), correspondant a la transition 
demandee, d'une extension (18) d'une table (13) d'actions si: 

- la transition demandee est autorisee (528, 521) 

30 - et, si les verifications associees a la transition 

demandee sont satisfaites (524) . 

26. Procede selon l'une quelconque des revendications 23 
a 25, caracterise en ce qu'il comprend en outre une etape 
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(525) d* execution d' actions negatives en exploitant une 
entree (407, 410," 413), correspondant a la transition 
demandee, d'une extension (18) d'une table (13) d' actions 
dans le cas ou les verifications associees a la transition 
5 demandee ne sont pas satisfaites (524) . 

27. Procede selon l'une quelconque des revendications 11 
a 26, caracterise en ce que ledit procede n'autorise pas le 
f ranchissement d'une transition d'etat, d f un etat additif 
10 vers un etat de reference. 
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A METHOD AND DEVICE FOR CONTROLLING THE LIFE CYCLE OF A 



The invention concerns portable electronic objects 
such as electronic microcircuit cards, known as smart 
cards, which, connected to electronic devices to enable 
the latter to perform particular functions in the 
context of one or more applications, require their life 
stages to be controlled. The said cards are in fact 
generally used in applications (banking, communication, 
identity, health etc) requiring a high degree of 
security against fraudulent usage. The invention 

applies more generally to any independent on-board 
system provided with a processing unit and program and 
data memories . 

In the world of smart cards it is known that the 
latter result from assembling a component (generally 
comprising a microprocessor in relationship with 
memories via communication buses) , a module (produced 
by means of a conductive metal) to which the said 



PORTABLE OBJECT, NOTABLY A SMART CARD 



component is connected (in the context of a so-called 
contact smart card) to enable the said component to be 
connected to an electronic reading and/or writing 
device (or coupler) and a card body or more generally a 
support on which the module/component assembly is 
integrated. In the context of a so-called contactless 
smart card, the said module is replaced by an antenna 
and the assembly formed by the component and the said 
antenna is integrated within the said support. 

The life of a smart card can generally be broken 
down into two sets of stages, following each other, 
corresponding respectively to the manufacture and use 
of the said card. Putting together the two sets of 
stages forms a life cycle of the said card. The 
manufacture of a smart card (with or without contact) 
consists of several stages. 

This is because it is first of all necessary to 
have an electronic component which is initialised, 
insulated and then connected to a module. The said 
component and the module to which it is connected are 
subsequently integrated on or within a support 
(generally a plastic card body) itself printed for the 
purpose of identification or advertising. Subsequently 
the smart card thus obtained is initialised or 
programmed in order to meet the conditions of use in 
the context of applications. 

The second set of life stages of a smart card 
corresponds to its use. This set can itself be divided 
into several stages, each corresponding, for example, 
to the implantation or elimination of services offered 
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by the smart card to the user according to his profile, 
for example . 

In addition different participants (component 
manufacturer, smart card manufacturer, card 

personalisation centre, card issuer or card carrier) 
act during the different stages of manufacture and use 
of a smart card. Thus the components are supplied and 
sometimes partly initialised by electronic component 
manufacturers on a silicon wafer. This phase 

corresponds to the step of manufacturing the component. 
The following step is the embedding phase carried out 
by the smart card manufacturer. It includes the 

insulation of a component from the silicon wafer, the 
connection of the said component to a module (or 
antenna) , and the integration of the assembly on the 
support or card body. There follows the preparation of 
the application structure present in the electrically 
programmable memory of the component. This is the 
electrical personalisation stage which is carried out 
by the manufacturer of the smart cards or by a 
personalisation "centre or a third party specialising in 
personalisation of cards or by the issuer himself who 
is ultimately responsible for the distribution of the 
cards on the market. This electrical personalisation 
phase can therefore be broken down into as many stages 
as there are players or intermediaries. Subsequently, 
during the use of the smart card, we have seen 
previously that it can be advantageous to distinguish 
several stages along with the change in the profile of 
the card user for example. 



Whatever the case, it is therefore important to 
rigorously monitor the life stages of a card in order 
to know at any time the current stage of the said card 
within its life cycle. In addition, it is essential on 
the one hand for access to the electrically 
programmable memory of a card component in write or 
read mode to be protected during the exchange of the 
said card (or component) during the different 
participants and on the other hand for access to the 
said memory to be limited as the life stages of the 
card mentioned above follow each other, by activating 
or deactivating services for example. Finally, it is 
also sometimes necessary to validate the application 
context of the smart card before the carrier thereof 
uses it on the market. For example, a person issuing a 
smart card of the electronic purse type must ' be certain 
that the balance of the said card is indeed zero before 
issuing the card. 

In order to attempt to meet these requirements, 
different solutions are used at the present time. 
Certain solutions are purely external to the smart card 
(physical security at the premises where the said card 
is manufactured, use of transportation means which are 
themselves made secure etc) . Other solutions 

complementary to the first, but this time internal or 
implanted in the card, are also generally used. Use is 
thus made of secrets for protecting access to the 
component memory in read/write mode and also logic 
indicators for irreversibly monitoring the different 
life stages of the card. For this purpose, bits within 
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a non-erasable memory of the component of the smart 
card are positioned at the active state at the end of 
the . different life stages of the card (manufacture and 
initialisation of the component by the manufacturer of 
the said component, embedding and initialisation of the 
card memory by the smart card manufacturer, preparation 
of the application structure of the smart card memory 
by the personalisation centre or the card issuer etc) . 
According to these indicators, the program (or 
operating system) executed by the microprocessor of the 
smart card component, implanted within one of the 
memories of the said card component, adapts its 
behaviour as the life stages of the said card follow 
each other. Thus functions can be modified, added or 
eliminated. 

Whatever the solutions used at the present time, 
they are all based on the fact that the different 
players involved in the manufacture of a card are 
trusted . third parties. Only persons liable to 

intercept components or cards during their transfer 
between two of the different players are deemed to be 
"potential fraudsters" and the solutions disclosed 
above make it possible to be free of them. The 
adaptation of the operating system of the card 
according to irreversible indicators affords a not 
insignificant advantage. Thus, if the manufacturers of 
the components or cards inscribe systems data or 
secrets, the card issuer will for example not be able 
to dispense freely with the said secrets or modify the 
said system data. However, this solution does not 
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resolve the problem of a fraudulent initialisation of 
the card or an inopportune error during the said 
initialisation, carried out by one of the participants. 

The invention proposes to remedy the drawbacks of 
the current state of the art. In particular, the 
invention consists of providing the operating system of 
a smart card with software means enabling the said 
operating system to control an irreversible change in 
life stage of the said card according to a set of 
checks on the content of the memories of this same 
smart card. In addition the invention makes provision, 
during a change in life stage, for the operating system 
of the card to be able to automatically trigger actions 
for adapting the services offered by the said operating 
system of the said card. 

To this end, the invention concerns a device for 
controlling the life cycle of a portable electronic 
object, the life cycle consisting of a succession of 
state transitions, the said states determining the 
services offered by the object, the said object 
comprising a processing unit, a volatile memory, 
program memories and data memories, each of these 
memories having a content defining a plurality of 
configurations, characterised in that it has means of 
controlling the transition from a first state to a 
second state of the portable electronic object. 

According to other characteristics of the device 
according to the invention: 

- the control means have: 



- means of enabling and/or inhibiting state 
transitions to be effected; 

means of checking the content of the 
volatile memory, of the data memories and of the 
program memories of the portable electronic object 
according to the state transition to be effected; 

- means for triggering actions during the 
processing of a request to effect a state 
transition. 

In addition, the invention concerns a portable 
electronic object, which may notably be a smart card, 
containing the said life cycle control device. 

Moreover, the invention concerns a method of 
controlling the life cycle of a portable electronic 
object, the said method being implemented within the 
object following^ a state transition request, 

characterised in that it comprises: 

- a step of validating the enabling of the said 
request ; 

- a step of evaluating the checks associated with 
the requested transition; 

- a step of modifying the current state of the 
object if and only if the requested transition is 
enabled and if the checks on the configuration of the 
object are satisfied. 

According to other characteristics, the method 
possibly also comprises: 

- a step of executing systematic actions; 

- a step of executing positive actions in the case 
where the requested transition is enabled and if the 
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checks associated with the requested transition are 
satisfied; 

- a step of executing negative actions in the case 
where the checks associated with the requested 
transition are not satisfied. 

The invention will be understood more clearly from 
a reading of the following description and an 
examination of the figures which accompany it. These 
are given only as an indication and are in no way 
limitative of the invention. 

The figures show: 

- Figure 1: a component of a smart card provided 
with a state transition check device; 

- Figures 2a and 2b: a detailed representation of 
a state transition table; 

Figure 3: a detailed representation of a 
transition check table; 

- Figure 4: a detailed representation of an action 

table; 

- Figure 5: a description of the steps implemented 
in the method used by the transition check device; 

Figures 6a to 6d: the particularities 
implemented in the case of an example of a smart card 
of the electronic purse type. 

In the invention, the term reference state will 
refer to a state from which it is possible to switch to' 
another state following the crossover of a transition 
described in the table of transitions, located in the 
program memory. As described below, it is possible to 
add new states and therefore new transitions after the 
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step of manufacturing the component has taken place. 
In this case, additive states will be spoken of in 
order to characterise these in contradistinction to 
reference states. In addition, the state in which the 
on-board system is will be referred to as the current 
state. 

Figure 1 shows a component 1, of a smart card, 
provided with a transition check device according to 
the invention. The component has a processing unit 2 
or a microprocessor in relationship with memories 3, 4 
and 5 via a communication bus 6. A non-erasable 
program memory 4 (or a ROM) has on the one hand a 
program area 7, the said programs (or on-board system) 
being able to be executed by the said processing unit 
and on the other hand a predefined data area 10 which 
contains constants used by the said operating system. 
Amongst the said constants of the area 10, the 
operating system 7, containing a program referred to as 
a check engine 9, uses a table of transitions 11 which 
makes it possible to specify the states to which it' is 
possible to gain access from the current state, a check 
table 12 which makes it possible to associate with each 
state transition checks relating to the content of the 
memories 3, 4 and/or 5. In a variant, the check engine 
9 can automatically trigger actions when a transition 
is crossed over or this crossover is rejected. For 
this purpose, the area 10 of the program memory 
contains a table of actions 13 which makes it possible 
to associate actions to be performed with each possible 
state transition. 
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A volatile memory 3 (or RAM, standing for Random 
Access Memory in English) enables the processing unit 2 
to temporarily store results or secrets issuing from 
calculations described by the programs implanted in the 
program memory 4. The content of the memory 3 is 
erased each time the component 1 is powered up or each 
time resetting thereof is requested. 

A data memory 5, electrically erasable, generally 
using EEPROM technology (standing for Electrically 
Erasable Programmable Read Only Memory in English) has 
an area 14 containing the variable data necessary for 
executing the programs 7. This area 14 contains 
notably a data item 8 referred to as the "current 
state" making it possible to store the current state of 
the portable electronic object. The data memory 5 also 
has an area 15 comprising optionally extensions to the 
tables 11 to 13 in the case where it is necessary to 
add states to the reference states. The area 15 then 
contains an extension to the table of transitions 16 
and an extension to the check table 17 and may include 
an extension to the table of actions 18 if it is. wished 
to associate actions with the' new additive state 
transitions, as seen previously with regard to table 
13. In the case of adding states with respect to the 
reference states, it is sometimes essential to enhance 
the operating system 7. For this purpose, the memory 5 
can also include an area 19 which contains the 
additional programs which will be executed in their 
turn by the processing unit 2 . 
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Figure 2a shows a possible use of the table of 
transitions 11. If it is assumed that i reference 
states are counted, it is possible to imagine a 
transition table comprising i columns and i rows. The 
columns correspond to the reference states which, at a 
given time, can be the current state. The first i rows 
correspond to the reference states to which access can 
be gained from the current state. Thus the value of a 
box in the table of transitions 11 corresponding to the 
intersection of a row and column in the said table 
makes it possible to code either the absence of an 
enabled transition (zero value for example - this is 
the case with the transition 20) or the enabling of a 
transition (non-zero value - this is the case with the 
transition 21). In the case of an enabled transition, 
the transition check engine searches within the check 
table 12 the checks to be made in order to accept or 
reject the crossover of the requested transition. 

Figure 2b also shows a possible implementation of 
a transition table in the case where it is possible to 
add states (additive states) to the reference states. 
The table of transitions includes an additional line 
compared with Figure 2a. The (i+l)th line makes it 
possible to specify if transitions from a current 
reference state to an additive state are enabled. Thus 
the value of the box 22 indicates an inhibited 
transition from a reference state to an additive state. 
The box 23 indicates that it will be possible to switch 
from the reference . state Ei to an additive state. An 
extension 16 to the table of transitions is then 
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necessary. The latter has j lines corresponding to j 
additive states to which it is possible to gain access 
from the (i+j) possible current states represented by 
the (i + j) columns of the extension 16 to the table of 
transitions. Thus the combination of the box 23 in the 
table of transitions and the box 24 of the extension 16 
of the table of transitions indicates to the check 
engine that it is possible to switch from the reference 
state Ei to the additive state E(i+1). 

Figure 3 shows a use of the check table. The 
check table 12 is located within the area 10 of the 
predefined data of the memory 4 . Each enabled 

transition has an entry in the said table. An entry 
comprises a field 30 for identifying the transition and 
a field 31 containing a reference (or address) to a 
program 32 of the operating system 7 . The check engine 
9 can thus make the processing unit 2 execute the 
required controls for accepting the crossover of the 
transition. Figure 3 also illustrates a structure of 
an extension 17 to the check table. In the same way as 
with the table 12, the extension to the check table 17 
has one entry per possible transition. Each entry 
comprises two fields, a field 33 for identifying the 
transition and a field 34 containing a reference (or 
address) of a program 35 of the operating system or, as 
shown by Figure 3, an additional program located in the 
data memory 5 (in the area 19) . 

Figure 4 shows a representation of the table of 
actions 13 located in the area 10 of the predefined 
data of the program area 4 . At the time of a 
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transition crossover request, it is possible to trigger 
actions. These can be of three types: systematic 
action, positive action (that is to say dependent on 
the fact that the checks are satisfactory) or negative 
action (that is to say dependent on the fact that the 
checks are not satisfactory) . Figure 4 shows that, at 
each enabled transition, there is an entry in the table 
of actions 13. This entry comprises four fields. The 
first field 400 identifies the transition. The other 
three fields 401, 402 and 403 each contain a reference 
or address of a program 404, 405 or 406 of the 
operating system. The field 401 is dedicated to a 
systematic action, the field 402 to a positive action 
and the field 403 to a negative action. Figure 4 also 
shows an extension 18 to the table of actions. This 
table 18 is located in the area 15 of the data memory 5 
of the component 1. In the same way as with the table 
of actions 13, the extension to the table of actions 18 
comprises one entry per possible transition. An entry 
comprises four fields. The first field 407 identifies 
the transition. The other three fields 408, 409 and 
410 each contain a reference or address of a program 
411, 412 or 413 of the operating system or, as shown by 
Figure 4, programs located in the area 19 of the data 
memory 5 of the component 1. The field 408 is 
dedicated to a systematic action, the field 409 to a 
positive action and the field 410 to a negative action. 

Figure 5a describes the method for validating or 
rejecting the crossover of a state transition, from a 
first reference state to another reference state. The 
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request for crossover of a transition can be formulated 
following an instruction from the card manufacturer or 
by any other player in the life cycle of the smart 
card. The said request can also be formulated directly 
by the card itself, for example through an action 
associated with a transition. In the context of Figure 
5a, the current reference state is the state Ei . The 
instruction 50 to switch from the state Ei to the state 
Ej is formulated. Step 51 consists of checking, within 
the table of transitions 11, that the transition from 
the state Ei to the state Ej is enabled. Where this 
transition is inhibited, the transition crossover 
request 50 is rejected. The current state remains the 
state Ei . On the other hand, if the transition is 
enabled, the check engine 9 executes the checks 
associated with the said transition. For this purpose 
the check engine evaluated the entry in the check table 
12 dedicated to the transition T(Ei->Ej). The execution 
of said checks corresponds to step 52 of the method. 
The check engine 9 executes the systematic actions 
associated with the transition T(Ei->Ej) according to 
the entry in the table of actions 13 dedicated to the 
said transition (step 53). If the checks 54 required 
at the time of the request for crossover of the 
transition 50 are not satisfactory, the current state 
remains unchanged. According to the entry in the table 
of actions 13 associated with the transition T(Ei— Ej) 
the check engine executes the negative actions *(step 55 
of the method) . The performance of the method is then 
terminated. On the other hand, if the checks 54 are 
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satisfactory, then the current state becomes the state 
Ej (step 56 of the method) . The positive actions are 
then executed (step 57 of the method) according to the 
state of the entry in the table of actions 13 
associated with the transition T(Ei->Ej). The 
performance of the method is terminated. 

Figure 5b describes the method for validating or 
rejecting the crossover of a state transition, from a 
first additive state to another additive state. The 
current additive state is the state Ei . The 
instruction 510 to switch from the additive Ei to the 
additive state (or reference state) Ej is formulated. 
Step 511 of the method consists of checking within the 
extension to the table of transitions 16 that the 
transition from state Ei to state Ej is enabled. Where 
this transition is inhibited, the transition crossover 
request 510 is rejected. The current state remains the 
state Ei . On the other hand, if the transition is 
enabled, the check engine 9 executes the checks 
associated with the said transition. For this purpose, 
the check engine evaluates the entry in the extension 
to the check table 17 dedicated to the transition 
T(Ei-*Ej). The execution of the said checks constitutes 
step 512 of the method. The check engine 9 executes 
the systematic actions associated with the transition 
T(Ei->Ej) according to the entry in the extension to the 
table of actions 18 dedicated to the said transition 
(step 513 of the method) . If the check 514 required at 
the time of the transition crossover request 510 is not 
satisfactory, the current state remains unchanged. 
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According to the entry in the extension to the table of 
actions 18 associated with the transition T(Ei-*Ej), the 
check engine 9 executes the negative actions (step 515 
of the method) . The performance of the method is then 
terminated. On the other hand, if the checks 514 are 
satisfactory, the current state becomes state Ej (step 
516 of the method) . The positive actions are then 
executed (step 517 of the method) according to the 
state of the entry in the extension to the table of 
actions 18 associated with the transition T(Ei-»Ej). 
The performance of the method is terminated. 

Figure 5c describes the method for validating or 
rejecting the crossover of a state transition, from a 
reference state to an additive state. The current 
reference state is the * state Ei . The instruction 520 
to switch from the reference state Ei to the additive 
state Ej is formulated. Step 528 of the method 
consists of checking, within the table of transitions 
11, that a transition from the current reference Ei to 
an additive state is enabled. If such a transition is 
inhibited, the method is terminated. The current state 
remains unchanged. On the other hand, if a transition 
from the said reference state to an additive state is 
enabled, the check engine runs steps 521 to 527 of the 
method, respectively identical to steps 511 to 517 
described in relation to Figure 5b. 

An example of an application in the field of 
electronic purses is presented in relation to Figures 
6a to 6d. The said application makes it possible to 
pay for purchases by means of "electronic money" stored 
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in a smart card, instead of paying in cash. The use of 
such a technique requires a management of the cards 
which is as secure as that which would have been 
imposed by the use of cash. It is necessary for 
example to avoid the creation of paper money. The 
security of an electronic purse smart card is generally 
based on keys stored, within the smart card allowing 
secure transactions using cryptography. Such a card 
has an operating system offering a set of commands and 
services for crediting or debiting money. At the start 
of the life cycle of the electronic purse smart card, 
the said smart card is not initialised. It contains no 
information. Figure 6a shows the predefined reference 
states: 

- State El "blank card" (referenced 80) : only test 
commands for validating the behaviour of the data 
memory 5 are available (verification that the EEPROM 
technology memory boxes can be correctly written to and 
erased) ; 

- State E2 "tested card" (referenced 82) : the test 
commands are no longer available. In their turn 
commands generally known as "physical commands" 
(allowing access in write mode by means of a physical 
addressing independently of any logic structure of the 
file type for example) are available. They make it 
possible to initialise the card (writing in the area 14 
of the data memory of the logic constituents necessary 
for the functioning of the application, that is to say 
files, balances etc) ; 
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- State E3 "initialised card" (referenced 84): the 
physical commands are no longer available. Logic 
commands for personalising the card (addition of new 
logic structures and initialisation data in the said 
structures) can be used. In addition, a recovery 
mechanism is activated so that the smart card does not 
lose the coherence of these data when it is powered 
down during the execution of one of the said logic 
commands; 

- State E4 "personalised card" (referenced 86): 
the logic commands specific to the electronic purse 
application (debit /credit ) are activated. 

The set of available commands changes according to 
the life stage in which the smart card is situated. 
Information stored in data memory enables the operating 
system to know the state in which the smart card is 
situated. Figure 6a also shows that, in the context of 
a card of the electronic purse type, all the 
transitions between reference states must be crossed 
successively (from state El to state E4), and this 
irreversibly. Any other transition is inhibited. Only 
the possibility of. subsequently using additive states 
88 is offered. This possible transition is referenced 
87. The operating system according to the current 
state allows only a set of commands specific to each 
reference state. 

The checks and actions to be triggered when a 
transition is crossed are described as follows: 

- . Transition from state El to state E2 (denoted 
T(E1->E2) and referenced 81): 
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- Check: none 

- Systematic action: 

erasure of the data memory in order to 
prevent a fraudster leaving therein data 
which can be interpreted by the card 
operating system; 

- Transition from state E2 to state E3 (denoted 
T(E2-E3) and referenced 83): 

- Check: 

- integrity of the data written in the 
data memory with the physical commands 
(validation of a redundancy code by data) ; 

- verification of the blank state of the 
memory apart from the said data; 

- Positive action: 

- activation of the recovery mechanism; 

- Transition from state E3 to state E4 (denoted 
T(E3->E4) and referenced 85): 

- Verification: 

nullity of the balance of the 
electronic purse 

- Action: none 

- Transition from state E4 to an additive state 
(denoted T(E4->Eadd) and referenced 87): 

- Verification: none 

- Action: none 

Figures 6b to 6d illustrate respectively an 
embodiment of a table of transitions 11, a check table 
12 and a table of actions 13, according to the 
invention. The table of transitions 11 as described in 
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relation to Figure 6b makes it possible to enable only 
the transitions 81, 83, 85 and 87. For this, only the 
boxes 60 to 63 in the said table contain a non-zero 
value. The other boxes in the table of transitions 
contain a zero value in order to indicate that any 
other transition is inhibited. The check table as 
presented through Figure 6c makes it possible to 
associate the checks to be' satisfied for enabling the 
crossover of the transitions 81, 83, 85 and 87, the 
said transitions enabled by the table of transitions 11 
(Figure 6b). Thus the entry 64 in the check table 12 
includes a field 641 for identifying the fact that the 
said entry is dedicated to the transition 81. The 
entry 64 also includes a field 642 containing a zero 
reference in order to indicate that no check is 
requested in order to allow the crossover of the 
transition 81. In a variant, the transition 81 has no 
associated entry. This variant is illustrated later in 
the case of the table of actions. The check table 12 
has an entry 65 which comprises respectively a field 
651 for indicating that the entry is associated with 
the transition 83 and a field 652 containing the 
reference of a program 67, located in the program 
memory, so that the check engine can make the checks 
described above. Likewise, the check table 12 has an 
entry 66 which comprises respectively a field 661 for 
indicating that the entry is associated with the 
transition 83 and a field 662 containing the reference 
of a program 68, located in the program memory, so that 
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the check engine can make the previously described 
checks . 

Figure 6d presents an embodiment of the table of 
actions 13. The said table has an entry 71 which 
includes a field 711 for indicating that the said entry 
is associated with the transition 81. The same entry 
71 has a field 712 containing the reference of a 
program 75, located in the program memory, so that the 
check engine can execute the systematic actions 
associated with the transition 81. The entry 71 also 
has a field 713 and a field 714 containing a zero 
reference in order to indicate to the check engine that 
no positive or negative action is associated with the 
crossover of the transition 81. In the same way, the 
table of actions 13 has a second entry 72 comprising 
the fields 721 to 724 in order to indicate to the check 
engine that the said entry is associated with the 
transition 83, that the program 74 is to be executed as 
a positive action when the said transition is crossed 
and that no systematic or negative action is to be 
executed. The absence of entry, within the table of 
actions 13, associated with the transition 85, 
indicates that no action (systematic, positive or 
negative) is to be executed at the time of crossover or 
rejection of crossover of the said transition. 

By means of the device and method as described 
above, the life cycle of a portable electronic object 
is controlled. Each state transition is irreversible 
and the checks made at the time of each transition 
request guarantee a coherent memory configuration for 
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the object. In addition, the systematic, positive or 
negative actions make it possible to adapt the 
behaviour of the said object. Finally, in the case 
where provision is made for enabling one or more 
transitions from one or more reference states to an 
additive state, the life cycle of the object can easily 
be enhanced, for example after the object is issued on 
the market, without the predefined life cycle (composed 
of a succession of transitions from one reference state 
to another reference state) being able to be diverted. 

Any risk of fraud during the initialisation of a 
portable electronic object or of an inopportune error 
during the said initialisation is removed whilst 
preserving great adaptability of control of the life 
cycle of the object. 
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CLAIMS 

1. A device for controlling the life cycle of a 
portable electronic object, the life cycle being 
determined by a succession of state transitions, the 
said states determining the services offered by the 
object, the said object comprising a processing unit 

(2) , a volatile memory (3), program memories (4) and. 
data memories (5), each of these memories (3, 4, 5) 
having a content defining a plurality of 
configurations , 

characterised in that it has means of controlling 
the transition from a first state to a second state of 
the portable electronic object. 

2. A device according to Claim 1, characterised 
in that the control means have means of enabling and/or 
inhibiting state transitions. 

3. A device according to either one of Claims 1 
or 2, characterised in that the control means comprise 
means of checking the content of the volatile memory 

(3) , the data memories (5) and the program memories (4) 
of the portable electronic object as a function of the 
state transition to be effected. 

4. A device according to any one of Claims 1 to 
3, characterised in that the control means comprise: 

- a. table (11) of possible state transitions; 

- a table (12) of the checks to be made per 
possible state transition; 

- a check engine (9) using the said tables. 
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5. A device according to any one of Claims 1 to 
4, characterised in that the control means also 
comprise means for triggering actions during the 
processing of a request for a transition from a first 
state to a second state of the portable electronic 
object . 

6. A device according to Claim 5, characterised 
in that the means for triggering actions during the 
processing of a request for transition from a first 
state to. a second state of the portable electronic 
object comprise a table (13) of actions which can be 
used by the said check engine (9) . 

7 . A device according to any one of Claims 1 to 

6, characterised in that the means of controlling the 
transition from a first state to a second state of the 
portable electronic object also comprise: 

- an extension (16) to the table (11) of possible 
state transitions ; 

- an extension (17) to the table (12) of checks to 
be made per possible state transition; 

and in that the check engine (9) uses the said 
table extensions (16, 17). 

8. A device according to any one of Claims 5 to 

7, characterised in that the means for triggering 
actions during the processing of a request for 
transition from a first state to a second state of the 
portable electronic object also comprise an extension 
(18) to the table (13) of actions which can be used by 
the check engine (9). 



9. A portable electronic object having a 
processing unit (2), a volatile memory (3), program 
memories (4) and data memories (5) , characterised in 
that it includes the device for controlling the life 
cycle of the object, according to one of Claims 1 to 8 . 

10. A smart card having a processing unit (2), a 
volatile memory (3), program memories (4) and data 
memories (5) , characterised in that it includes the 
device for controlling the life cycle of the object, 
according to one of Claims 1 to 8. 

11. A method of controlling the life cycle of a 
portable electronic object, the life cycle being 
determined by a succession of state transitions, the 
said states determining the services offered by the 
object, the said object comprising a processing unit 
(2), a volatile memory (3), program memories (4) and 
data memories (5), each of these memories (3, 4, 5) 
having a content defining a plurality of 
configurations , 

the said method being implemented, within the 
object, following a state transition request, 
characterised in that it comprises: 

- a step (51, 511, 528, 521) of validation of the 
enabling of the said request; 

- a step (52, 512, 522) of evaluating the checks 
associated with the requested transition; 

- a step (57, 517, 527) of modifying the current 
state of the object if and 'only if the requested 
transition is enabled (51, 511, 528, 521) and if the 
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checks on the configuration of the object are satisfied 
(54, 514, 524) . 

12. A method according to Claim 11, characterised 
in that it also comprises a step (53, 513, 523) of 
executing systematic actions. 

13. A method according to either one of Claims 11 
or 12, characterised in that it also comprises a step 
(56, 516, 526) of executing positive actions in the 
case where the requested transition is enabled (51, 
511, 528, 521) and if the checks associated with the 
requested transition are satisfied (54, 514, 524). 

14. A method according to any one of Claims 11 to 

13, characterised in that it also comprises a step (55, 
515, 525) of executing negative actions in the case 
where the checks associated with the requested 
transition are not satisfied (54, 514, 524). 

15. A method according to any one of Claims 11 to 

14, implemented within the object, following a request 
for transition from a first reference state to a second 
reference state, characterised in that it comprises: 

- a step (51) of validating the enabling of the 
said request consisting of analysing the table (11) of 
possible transitions ; 

- a step (52) of evaluating the checks associated 
with the requested transition consisting of using an 
entry (30) in a table (12) of checks; 

- a step (57) of modifying the current state of 
the object if and only if the requested transition is 
enabled (51) and if the checks on the configuration on 
the object are satisfied (54). 
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16. A method according to Claim 15, characterised 
in that it also comprises a step (53) of executing 
systematic actions consisting of using an input (400, 
401, 404), corresponding to the requested transition, 
of a table of actions (13) . 

17. A method according to either one of Claims 15 
or 16, characterised in that it also comprises a step 
(56) of executing positive actions consisting of using 
an entry (400, 402, 405) , corresponding to the 
requested transition, in a table (13) of actions, in 
the case where the requested transition is enabled (51) 
and if the checks associated with the requested 
transition are satisfied (54). 

18. A method according to any one of Claims 15 to 
17, characterised in that it also comprises a step (55) 
of executing negative actions consisting of using an 
entry (400, 403, 406) , corresponding to the requested 
transition, in the table (13) of actions, in the case 
where the checks associated with the requested 
transition are not satisfied (54). 

19. A method according to any one of Claims 11 to 
14, the said method being implemented within the 
object, following a request for transition from a first 
additive state to a second additive state, 
characterised in that it comprises: 

- a step (511) of validating the enabling of the 
said request consisting of analysing an extension (16) 
of the table (11) of possible transitions; 

- a step (512) of evaluating the checks associated 
with the requested transition consisting ' of using an 
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entry (33) in an extension (17) to the table (12) of 
checks; 

- a step (517) of modifying the current state of 
the object if and only if the requested transition is 
enabled (511) and if the checks on the configuration of 
the object are satisfied (514). 

20. A method according to Claim 19, characterised 
in that it also comprises a step (513) of executing 
systematic actions by analysing an entry (407, 408, 
411) , corresponding to the requested transition, with 
an extension (18) to a table (13) of actions. 

21. A method according to either one of Claims 19 
or 20, characterised in that it also comprises a step 

(516) of executing positive actions by analysing an 
entry (407, 409, 412), corresponding to the requested 
transition, in an extension (18) of a requested table 

(13) of actions if: 

- the requested transition is enabled (511) 

- and if the checks associated with the requested 
transition are satisfied (514). 

22. A method according to any one of Claims 19 to 
21, characterised in that it also comprises a step 
(515) of executing negative actions by analysing an 
entry (407, 410, 413), corresponding to the requested 
transition, in an extension (18) to a table (13) of 
actions in the case where the checks associated with 
the requested transition are not satisfied (514). 

23. A method according to any one of Claims 11 to 
14, the said method being implemented, within the 
object, following a request for transition from a 
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reference state to an additive state, characterised in 
that it comprises: 

- a step (528) of validating the enabling of a 
transition from the said reference state to an additive 
state by analysing the table (11) of possible 
transitions ; 

- a step (521) of validating the enabling of a 
transition from the said reference state to the said 
additive state using an extension (16) to a table (11) 
of possible transitions; 

- a step (522) of evaluating the checks associated 
with the requested transition using an entry (33) in an 
extension (17) to a table (12) of checks; 

- a step (527) of modifying the current state of 
the object if and only if the requested transition is 
enabled (528, 521) and if the checks on the 
configuration of the object are satisfied (524). 

24. A method according to Claim 23, characterised 
in that it also comprises a step (523) of executing 
systematic actions using an entry (407, 408, 411), 
corresponding to the requested transition, in an 
extension (18) to a table (13) of actions. 

25. A method according to either one of Claims 23 
or 24, characterised in that it also comprises a step 
(526) of executing positive actions using an entry 
(407, 409, 412), corresponding . to the requested 
transition, in an extension (18) to a table (13) of 
actions if: 

- the requested transition is enabled (528, 521) 
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- and if the checks associated with the requested 
transition are satisfied (524). 

26. A method according to any one of Claims 23 to 

25, characterised in that it also comprises a step 
(525) of executing negative actions using an entry 
(407, 410, 413), corresponding to the requested 
transition, in an extension (18) to a table (13) of 
actions in the case where the checks associated with 
the requested transition are not satisfied (524) . 

27. A method according to any one of Claims 11 to 

26, characterised in that the said method does not 
enable the crossover of a state transition, from an 
additive state to a reference state. 
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INTERNATIONAL PRELIMINARY EXAMINATION REPORT 



Internationa) application No. 

PCT/FR99/02678 



I. Basis of the report 



1. With regard to the elements of the international application:* 
| [ the international application as originally filed 

the description: 

pages 

pages 

pages 



, as originally filed 



filed with the demand 



1-19 



, filed with the letter of 20 December 2000 (20. 1 2.2000) 



the claims: 

pages 

pages 

pages 

pages 



, as originally filed 

, as amended (together with any statement under Article 19 

, filed with the demand 



1-36 



filed with the letter of 20 December 2000 (20.12.2000) 



the drawings: 

pages 

pages 

pages 



1/5-5/5 



, as originally filed 
, filed with the demand 



..filed with the letter of 



| | the sequence listing part of the description: 

pages 

pages 

pages 



, as originally filed 



filed with the demand 



filed with the letter of 



2. With regard to the language, all the elements marked above were available or furnished to this Authority in the language in which 
the international application was filed, unless otherwise indicated under this item. 

These elements were available or furnished to this Authority in the following language which is: 

| | the language of a translation furnished for the purposes of international search (under Rule 23.1(b)). 
| | the language of publication of the international application (under Rule 48.3(b)), 

| | the language of the translation furnished for the purposes of international preliminary examination (under Rule 55.2 and/ 
or 55.3). 

With regard to any nucleotide and/or amino acid sequence disclosed in the international application, the international 
preliminary examination was carried out on the basis of the sequence listing: 

contained in the international application in written form. 

filed together with the international application in computer readable form. 

furnished subsequently to this Authority in written form. 

furnished subsequently to this Authority in computer readable form. 

The statement that the subsequently furnished written sequence listing does not go beyond the disclosure in the 
international application as filed has been furnished. 

The statement that the information recorded in computer readable form is identical to the written sequence listing has 
been furnished. 



□ 
□ 
□ 
□ 
□ 

□ 
□ 



The amendments have resulted in the cancellation of: 

1 | the description, pages 

| | the claims, Nos. 

I | the drawings, sheets/fig 



□ This report has been established as if (some of) the amendments had not been made, since they have been considered to go 
beyond the disclosure as filed, as indicated in the Supplemental Box (Rule 70.2(c)).** 

* Replacement sheets which have been furnished to the receiving Office in response to an invitation under Article 14 are referred to 
in this report as "originally filed" and are not annexed to this report since they do not contain amendments (Rule 70.10 
and 70.17). 

** Any replacement sheet containing such amendments must be referred to under item I and annexed to this report. 
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1 . Statement 

Novelty (N) 

Inventive step (IS) 



Industrial applicability (IA) 



Citations and explanations 



Claims 
Claims 

Claims 
Claims 

Claims 
Claims 



1-36 



1-36 



1-36 



YES 
NO 
YES 
NO 

YES 
NO 



Reference is made to the following document: 
Dl: US-A-5473690 

1. The invention concerns a device for controlling the 
life cycle of a portable electronic object, the life 
cycle being determined by a succession of states of 
transition, said states determining the services 
offered by the card. This invention also concerns a 
method for controlling the life cycle of a portable 
electronic object. 



The closest prior art is Dl, which describes a smart 
card that is capable of containing several distinct 
applications, for example, relating to a bank, 
garage, social security, etc... Access to each of its 
applications is protected by a different password 
(see Figure 3, and the corresponding description). 
The passing from one application to another 
corresponds to a state of transition of the card. 
Furthermore, the life cycle of the card is 
characterised by numerous transitions from one 
^Plication t o another, and, hence, from one state 

Form PCT/IPEA/409 (Box V) (January 1994) 
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"ternational application No. 
PCT/FR 99/02678 



of the card to another. Since the access to each 
application is protected by a password, it is 
implicit that the card comprises means of 
controlling the validity of passwords, hence, 
constituting a means for controlling the transition 
from one state to another. Furthermore, the card 
also comprises a processing unit (11; Figure 2), a 
volatile memory (registers of microprocessor 3), 
program memories (13), and data memories (12), each 
of these memories having a content defining a 
plurality of configurations. 



The objective problem of Dl solved by the present 
invention can be considered to be that of providing 
an irreversible passage of the object from one state 
to another, in the course of the card life cycle, in 
particular for reasons of security. 

The invention solves this problem by the fact that 
the control device comprises means for controlling 
the transition of the portable electronic object 
from a first to a second state, by using state 
transition authorisation and/or blocking means, such 
that only some transitions among all possible 
transitions are permitted. 



No single cited document in the International Search 
Report suggests such a control of transition from 
one state to another. m Dl, there is nothing to 
prevent passing from one application to another if 
the password is known. 
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| VII. Certain defects in the international application 



:mational application No. 
PCT/FR 99/02678 



The following defects in the form or contents of the international application have 



been noted: 



The description is not in 



accordance with the claims, a 



re 



quxred by PCT Rule 5.1(a) (ill), with reS pect to the 
definition of the invention on pages 5 to 7 . 
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(article 36 et regie 70 du PCT) 




Reference du dossier du deposant ou du 
mandataire 

GEM 555 


voir la notification de transmission du rapport d'examen 
POUR SUITE A DONNER preliminaire international (formulaire PCT/IPEA/416) 


Demande Internationale n° 
PCT/FR99/02678 


Date du depot international (jour/mois/ann6e) 
03/11/1999 


Date de priorite Qour/mois/ann^e) 
13/11/1998 


Classification Internationale des brevets (CIB) ou a la fois classification nationale et CIB 
G06K1 9/073 


Deposant 

GEMPLUS etal. 



1 . Le present rapport d'examen preliminaire international, etabli par I'administaration chargee de I'examen preliminaire 
international, est transmis au deposant conformement a I'article 36. 

2. Ce RAPPORT comprend 5 feuilles, y compris la presente feuille de couverture. 

S || est accompagne d'ANNEXES, c'est-a-dire de feuilles de la description, des revendications ou des dessins qui ont 
ete modifiees et qui servent de base au present rapport ou de feuilles contenant des rectifications faites aupres de 
I'administration chargee de I'examen preliminaire international (voir la regie 70.16 et Instruction 607 des Instructions 
administratives du PCT). 

Ces annexes comprennent 29 feuilles. 



3. Le present rapport contient des indications relatives aux points suivants: 



Base du rapport 



II 


□ 


III 


□ 


IV 


□ 


V 


IS 


VI 


□ 


VII 




VIII 


□ 



d'application industrielle 



Declaration motivee selon radicle 35(2) quant a la nouveaute, I'activite inventive et la possibility 
d'application industrielle; citations et explications a I'appui de cette declaration 



Irregularis dans la demande internationale 



Date de presentation de la demande d'examen preliminaire 
internationale 

25/05/2000 



Date d'achevement du present rapport 
14.02.2001 



Norn et adresse postale de I'administration chargee de 
I'examen preliminaire international: 
Office europeen des brevets 

D-80298 Munich 
Tel. +49 89 2399 - 0 Tx: 523656 epmu d 

Fax: +49 89 2399 - 4465 



Fonctionnaire autorise 
Paci, M 

N° de telephone +49 89 2399 2282 



Formulaire PCT/IPEA/409 (feuille de couverture) (janvier 1994) 



RAPPORT D'EXAMEN 
PRELIMINAIRE INTERNATIONAL 



Demande internationale n° PCT/FR99/02678 



I. Base du rapport 

1 . Ce rapport a £t£ r£dig§ sur la base des elements ci-apr&s (les feuilles de remplacement qui ont 6t6 remises £ 
i'office r6cepteur en r£ponse £ une invitation faite conform£ment £ i'articie 14 sont consid£r&es dans le present 
rapport comme "initialement d£pos£es" et ne sont pas jointes en annexe au rapport puisqu'eties ne contiennent 
pas de modifications (regies 70. 16 et 70. 17).) : 

Description, pages: 

1 -1 9 regue(s) le 27/1 2/2000 avec la lettre du 20/1 2/2000 
Revendications, N°: 

1-36 re$ue(s) le 27/12/2000 avec la lettre du 20/12/2000 
Dessins, feuilles: 

1/5-5/5 version initiale 

2. En ce qui concerne la langue, tous les elements indiqu£s ci-dessus £taient k la disposition de ('administration ou 
lui ont ete remis dans la langue dans laquelle la demande internationale a 6t6 d6pos6e, sauf indication contraire 
donnee sous ce point. 

Ces elements etaient k la disposition de I'administration ou lui ont £t£ remis dans la langue suivante: , qui est : 

□ la langue d'une traduction remise aux fins de la recherche internationale (selon la rkg\e 23.1(b)). 

□ la langue de publication de la demande internationale (selon la regie 48.3(b)). 

□ la langue de la traduction remise aux fins de I'examen pr6liminaire internationale (selon la rkgle 55.2 ou 
55.3). 

3. En ce qui concerne les sequences de nucleotides ou d'acide amines divulgu^es dans la demande 
internationale (le cas §ch£ant), I'examen pr^liminaire internationale a 6t6 effectu6 sur la base du listage des 
sequences : 

□ contenu dans la demande internationale, sous forme 6crite. 

□ d6pos6 avec la demande internationale, sous forme d£chiffrable par ordinateur. 

□ remis ulterieurement & I'administration, sous forme 6crite. 

□ remis ulterieurement k I'administration, sous forme d£chiffrable par ordinateur. 

□ La declaration, selon laquelle le listage des sequences par £crit et fourni ulterieurement ne va pas au-del& 
de la divulgation faite dans la demande telle que d^posee, a et6 fournie. 

□ La declaration, selon laquelle les informations enregistr£es sous d£chiffrable par ordinateur sont identiques k 
celles du listages des sequences Presents par 6crit, a £t£ fournie. 

4. Les modifications ont entrain^ I'annulation : 
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□ de la description, pages : 

□ des revendications, n os : 

□ des dessins, feuilles : 

5. □ Le present rapport a £t£ formula abstraction faite (de certaines) des modifications, qui ont 6t6 consid6r§es 
comme allant au-del& de I'expose de I'invention tel qu'il a 6t£ d6pos6, comme il est indiqu£ ci-apres (r£gle 
70.2(c)) : 



(Toute feuille de remplacement comportant des modifications de cette nature doit etre indiquge au point 1 et 
annex£e au present rapport) 



6. Observations compl6mentaires, le cas 6ch§ant : 



V. Declaration motivee selon I'article 35(2) quant a la nouveaute, I'activite inventive et la possibility 
d'application industrielle; citations et explications a I'appui de cette declaration 

1. Declaration 



Nouveaute Oui : Revendications 1 -36 

Non : Revendications 

Activity inventive Oui: Revendications 1-36 

Non : Revendications 

Possibility d'application industrielle Oui : Revendications 1 -36 

Non : Revendications 



2. Citations et explications 
voir feuille separee 



VII. Irregularis dans la demande internationale 

Les irr6gularit6s suivantes, concernant la forme ou le contenu de la demande internationale, ont 6t6 constat6es : 
voir feuille separee 



Formulaire PCT/IPEA/409 (cadres l-VIII, feuille 2) Quillet 1998) 



RAPPORT D'EXAMEN Demande internationale n° PCT/FR99/02678 
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Cone rnant I p int V 

Declaration motivee selon I'article 35(2) quant a la nouveaute, I'activite inventiv 
et la possibility d'application industrielle; citations et explications a I'appui de 
cette declaration 

II est fait reference au document suivant: 

D1: US-A-5473690 

1 . L'invention concerne un dispositif de controle du cycle de vie d'un objet 
electronique portatif, le cycle de vie etant determine par une succession de 
transitions d'etats, lesdits etats determinant les services offerts par la carte, 
[.'invention concerne egalement un procede de controle du cycle de vie d'un objet 
electronique portatif. 

L'etat de la technique le plus proche est D1 qui decrit un carte a puce pouvant 
contenir plusieurs applications distinctes concernant par exemple une banque, un 
garage, la sec u rite sociale, etc... L'acces a chacune de ces applications est 
protege par un mot de passe different (voir figure 3 et la description 
correspondante). Le passage d'une application a une autre correspond a une 
transition d'un etat de la carte a un autre etat de la carte. De plus, le cycle de vie 
de la carte est caracterise par de nombreux passages d'une application a une 
autre, et done d'un etat de la carte a un autre. Etant donne que l'acces a chaque 
application est protege par un mot de passe, il est implicite que la carte comporte 
des moyens de controle de la validite des mots de passe constituant done un 
dispositif de controle de la transition d'un etat a un autre. De plus, la carte 
comprend egalement une unite de traitement (1 1 ; figure 2), une memoire volatile 
(les registres du microprocesseur 3), des memoires de programme (13) et des 
memoires de donnees (12), chacune de ces memoires presentant un contenu 
definissant une pluralite de configurations. 

Le probleme objectif de D1 resolu par la presente invention est permettre un 
passage irreversible d'un etat a un autre etat de I'objet au cours du cycle de vie 
de la carte, notamment pour des raisons de securite. 
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L'invention resout ce probleme en ce que le dispositif de controle comporte des 
moyens de controle de la transition d'un premier etat a un second etat de I'objet 
electronique portatif, exploitant des moyens d'autorisation et/ou interdiction de 
transition d'etat, de sorte que seules certains transitions ne soient permises parmi 
('ensemble des transitions possibles. 

Aucun des documents cites dans le rapport de recherche international ne suggere 
un tel controle du passage d'un etat a un autre. Dans D1 , rien n'empeche de 
passer d'une application a une autre si Ton connaTt le mot de passe. 

Concernant le point VII 

Irregularites dans la demande intemationale 

La description ne concorde pas avec les revendications, comme I'exige la regie 
5.1 a) iii) PCT, en ce qui concerne la definition de l'invention aux pages 5 a 7. 
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PROCEDE ET DISPOSITIF DE CONTROLE DU CYCLE 
DE VIE D'UN OB JET PORTATIF, NOTAMMENT D'UNE 

CARTE A PUCE 



L ' invention concerne les objets electroniques portatifs 
tels que les cartes a microcircuits electroniques, dites 
cartes a puce qui, connectees a des dispositifs 
5 electroniques pour permettre a ces derniers de realiser des 
fonctions particulidres dans le cadre d'une ou plusieurs 
applications, necessitent un contr61e de leurs etapes de 
vie. Lesdites cartes sont en effet generalement utilisees 
dans des applications' (banque, communication, identite, 

10 sant<§...) necessitant une grande securite contre les usages 
frauduleux. Ainsi, a titre d'exemple, le document US 
5473690 presente une carte a puce comprenant plusieurs 
applications dont 1 ' accds est protege par mots de passe, un 
mot de passe etant dedi£ a un utilisateur. Connaissant un 

15 mot de passe, il est possible de selectionner telle ou 
telle application. Cependant, on ne peut desactiver une 
application ou en limiter 1' usage quel que soit 
1' utilisateur de la carte en fonction des etapes de vie de 
ladite carte. 

2 0 L' invention s' applique plus generalement a tout systeme 

embarque independant, dote d'une unite de traitement et des 
memoires de programme et de donnees . 

II est connu dans le monde de la carte a puce que 
25 celle-ci resulte d 1 un assemblage d'un composant (comprenant 
en general un microprocesseur en relation avec des memoires 
via des bus de communication), d'un module (realise a 
l'aide d'un metal conducteur) auquel est relie ledit 
composant (dans le cadre d'une carte a puce dite a contact) 
30 pour permettre audit composant d ' @tre connecte a un 
dispositif electronique de lecture et/ou ecriture (ou 
coupleur) et d'un corps de carte ou plus generalement d'un 
support sur lequel est integre 1' ensemble modul e/ compos ant . 
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Dans la cadre d'une carte a puce dite sans contact, ledit 
module est remplace par une antenne et l 1 ensemble forme par 
le composant et ladite antenne est inttgree au sein dudit 
support . 

5 La vie d'une carte a puce se decompose generalement en 

deux ensembles d 1 etapes se succedant les unes aux autres, 
correspondant respect ivement a la fabrication et a 
1 1 exploitation de ladite carte. La composition des deux 
ensembles d'etapes forme un cycle de vie de ladite carte. 

10 La fabrication d'une carte a puce (a contact ou sans 
contact) est constitute de plusieurs etapes. 

En effet, il est tout d'abord necessaire de disposer 
d'un composant electronique qui est initialise, isole, puis 
relie a un module. Ledit composant et le module, auquel il 

15 est relie, sont par la suite integres sur ou au sein d'un 
support (generalement un corps de carte plastique) lui meme 
imprime a des fins d 1 identification ou de publicite. Par la 
suite la carte a puce ainsi obtenue est initialisee ou 
programmee pour repondre aux conditions d 1 utilisation dans 

20 le cadre d ' applications . 

Le second ensemble d' etapes de vie d'une carte a puce 
correspond a son exploitation. Cet ensemble peut lui -meme 
etre divise en plusieurs etapes, chacune correspondant, par 
exemple, a 1 1 implantation ou la suppression de services 

25 offerts par la carte a puce a 1 1 utilisateur en fonction de 
son profil par exemple. 

En outre differents acteurs (fabricant de composant, 
fabricant de cartes a puce, centre de personnalisation de 
cartes, emetteur de cartes, ou encore porteur de cartes) 

3 0 interviennent durant les differentes etapes de la 
fabrication et de 1 • exploitation d'une carte a puce. Ainsi, 
les composants sont fournis et parfois en partie 
initialises par des fabricants de composants electrohiques 
sur une tranche de silicium. Cette phase correspond a 

35 l'etape de fabrication du composant. L'etape suivante est 
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la phase d'encartage rgalisee par le fabricant de carte a 
puce. Elle inclut 1 ' isolement d'un composant de la tranche 
de silicium, la connexion dudit composant a un module (ou 
antenne) , 1 ' integration de 1 ' ensemble • sur leur support ou 
corps de carte. Suit la preparation de la structure 
applicative presente dans la memoire programmable 
electriquement du composant. C'est l'<§tape de 
personnalisation electrique qui est realisee par le 
fabricant des cartes a puce ou par un centre de 
personnalisation ou un tiers specialise dans la 
personnalisation des cartes ou par l'emetteur lui-meme qui 
est charge in fine de la distribution des cartes sur le 
marche. Cette phase de personnalisation electrique peut 
done etre decomposed en autant d' etapes qu'il y a d' acteurs 
15 ou d'interm£diaires. Par la suite, durant 1 ■ exploitation de 
la carte a puce, nous avons vu precedemment qu'il peut €tre 
interessant de distinguer differentes etapes au gre de 
1' evolution du profil de 1 ' utilisateur de la carte par 
exemple. Pour toutes ces raisons, il est done important de 
suivre rigoureusement les etapes de vie d'une carte pour 
connaitre a tout moment 1 ' etape en-cours de ladite carte au 
sein de son cycle de vie. De plus, il est indispensable 
que, d'une part, l'acces en ecriture ou en lecture de la 
memoire programmable electriquement du composant d'une 
25 carte soit protege durant 1 ' echange de ladite carte (ou du 
composant) entre les differents acteurs et que d' autre part 
l'acces a ladite memoire soit limite au fur et a mesure que 
se succedent les etapes de vie de la carte citees 
precedemment, en activant ou desactivant des services par 
3 0 exemple. Pour finir, il est egalement necessaire parfois de 
valider le contexte applicatif de la carte a puce avant que 
le porteur de celle-ci 1' utilise sur le marche. Par 
exemple, un emetteur de carte a puce de type porte-monnaie 
61ectronique, doit etre certain que la balance de ladite 
35 carte est bien nulle avant d'emettre la carte. 



20 
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Pour tenter de repondre a ces exigences, differentes 
solutions sont utilisees a ce jour. Certaines solutions 
sont purement exterieures a la carte a puce (securisation 
physique des locaux ou ladite carte est fabriquee, 
utilisation de moyens de transport eux-memes securises . . . ) . 
D'autres solutions complement aires aux premieres, mais 
cette fois internes ou implantees dans la carte, sont aussi 
generalement utilisees. On utilise ainsi des secrets 
permettant de proteger 1 1 acces en lecture/ecriture de la 
memoire du composant et egalement des indicateurs logiques 
permettant de suivre de maniere irreversible les 
differentes etapes de vie de la carte. Pour cela, des bits 
au sein d'une memoire non effagable du composant de la 
carte a puce sont positionnes a l'etat actif a la fin des 
differentes etapes de vie de la carte (fabrication et 
initialisation du composant par le fabricant dudit 
composant, encartage et initialisation de la memoire de la 
carte par le fabricant de carte a puce, preparation de la 
structure applicative de la memoire de la carte a puce par 
le centre de personnalisation ou l'emetteur de la 
carte...). En fonction de ces indicateurs, le programme, (ou 
systeme d 1 exploitation) , execute par le microprocesseur du 
composant de la carte a puce, implant e au sein de I'une des 
memoires dudit composant de ladite carte, adapte son 
comport ement au fur et a mesure que les etapes de vie de 
ladite carte se succedent . Ainsi, des fonctions peuvent 
etre modifiees, ajoutees ou supprimees. 

Quelles que soient les solutions utilisees a ce jour, 
elles reposent toutes sur le fait que les differents 
acteurs impliques dans la fabrication d'une carte sont des 
tiers de confiance. Seules des personnes, susceptibles 
d ' intercepter des composants ou des cartes durant leur 
transfert entre deux des differents acteurs, sont supposees 
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"fraudeurs potentiels" et les solutions exposees 
precedemment permettent de s 1 en affranchir. L 1 adaptation du 
systeme d ' exploitation de la carte en fonction des 
indicateurs irreversibles apporte un plus non negligeable. 
5 Ainsi, si les fabricants de composants ou de cartes 
inscrivent des donnees systemes ou des secrets, l'emetteur 
de la carte ne pourra par exemple librement s' affranchir 
desdits secrets ou modifier lesdites donnees systeme. 
Cependant, cette solution ne resout pas le probleme d'une 
10 initialisation frauduleuse de la carte ou d'une erreur 
malencontreuse durant ladite initialisation, effectuee par 
I'un des acteurs. 



L 1 invention propose de remedier aux inconvenients de 
15 I'etat actuel de la technique. En particulier, 1 1 invention 
consiste a doter le systeme d 1 exploitation d'une carte a 
puce de moyens logiciels perraettant audit systeme 
d ! exploitation de maitriser un . changement irreversible 
d'etape de vie de ladite carte en fonction d ! un ensemble de 
2 0 verifications du contenu des memoires de cette rneme carte a 
puce. En outre 1 ! invention prevoit que lors d'un changement 
d'etape de vie, le systeme d ' exploitation de la carte 
puisse declencher automat iquement des actions permettant 
d* adapter les services offerts par ledit systeme 
25 d' exploitation de ladite carte. 



A cet effet, 1 1 invention concerne un dispositif de 
controle du cycle de vie d'un objet electronique portatif, 
le cycle de vie etant constitue par une succession de 
transitions d'etats, lesdits etats determinant les services 
offerts par 1' objet, ledit objet comprenant une unite de 
traitement, une me moire volatile, des memoires de 
programmes et des memoires de donnees, chacune de ces 
memoires presentant un contenu definissant une pluralite 
de configurations, characterise en ce qu'il comporte des 
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moyens de controle de la transition d'un premier etat a un 
second etat de 1' objet electronique portatif. 

Selon d'autres caracteristiques du dispositif selon 
1 1 invention : 

- les moyens de controle comport ent : 

- des moyens d' autorisation et/ou d' interdiction de 
transition d'etats a effectuer; 

- des moyens de verification du contenu de la 
memoire volatile, des memoires de donnees et des 
memoires de programme de 1' objet electronique 
portatif en fonction de la transition d'etats a 
effectuer; 

- des moyens permettant de declencher des actions 
15 lors du traitement d'une demande de f ranchissement 

d'une transition d'etat. 

En outre, 1' invention concerne un objet electronique 
portatif, pouvant etre notamment une carte a puce, 
comportant ledit dispositif de controle du cycle de vie. 



20 



Par ailleurs, 1' invention concerne un procede de 
controle du cycle de vie d'un objet electronique portatif, 
ledit procede etant mis en osuvre au sein de 1' objet a la 
2 5 suite d'une demande de transition d'etats, 

caracterise en qu ! il comprend : 

- une etape de validation de 1 * autorisation de ladite 
demande ; 

- une etape devaluation des verifications associee a 
30 la transition demandee ; 

- une etape de modification de l'etat courant de 
1' objet si et seulement si la transition demandee 
est autorisee et, si les verifications de la 
configuration de 1' objet sont satisfaites. 

35 
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Selon d'autres caracteristiques, le procede comprend 
eventuellement en outre : 

une etape d' execution d' actions systematiques ; 
une etape d 1 execution d' actions positives dans le 
5 cas ou la transition demandee est autorisee et si 

les verifications associees a la transition demandee 
sont satisfaites; 

une etape d' execution d ! actions negatives dans le 
cas ou les verifications associees a la transition 
10 demandee ne sont pas satisfaites. 

L 1 invention sera mieux comprise a la lecture de la 
description qui suit et a 1 1 examen des figures qui 
1 ' accompagnent . Celles-ci ne sont donnees qu'a titre 
15 indicatif et nullement limitatif de l 1 invention. 
Les figures montrent : 

figure 1: un composant d'une carte a puce munie d'un 
dispositif de verification de transition d'etat; 
figures 2a et 2b: une representation detaillee d'une 
2 0 table des transitions d'etat; 

figure 3: une representation detaillee d'une table 
des verifications des transitions; 

figure 4: une representation detaillee d'une table 
des actions; 

25 - figure 5: une description des etapes mises en ouvre 

dans le procede utilise par le dispositif de 
verification de transitions; 

figures 6a a 6d: les particularites mises en ceuvre 
dans le cas d'un exemple d'une carte a puce de type 
30 porte-monnaie electronique . 

Dans l f invention, on appellera etat de reference, un 
etat a partir duquel il est possible de basculer vers un 
autre etat suite au f ranchissement d'une transition decrite 
35 dans la table des transitions, implantee dans la memoire de 
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programme. Comme il est decrit plus loin, il est possible 
d'aj outer de nouveaux etats et done de nouvelles 
transitions aprds que l'Stape de fabrication du composant 
ait eu lieu. Dans ce cas, on parlera d' etats additifs pour 
caracteriser ceux-ci par opposition aux etats de reference. 
D ' autre part, on appellera etat courant l'etat dans lequel 
se trouve le systeme embarque. 

La figure 1 montre un composant 1, d'une carte & puce, 
muni d'un dispositif de verification de transitions selon 
1' invent ion. Le composant comporte une units de traitement 
2 ou encore microprocesseur en relation avec des memoires 
3, 4 et 5 via un bus de communication 6. Une memoire de 
programme 4 (ou encore ROM) non effagable comporte d'une 
part une zone de programmes 7, lesdits programmes (ou 
encore systeme d • exploitation du systdme embarque) pouvant 
§tre executes par ladite unite de traitement et d' autre 
part une zone de donnees predefinies 10 qui contient des 
constantes utilisees par ledit systeme d- exploitation. 
Parmi lesdites constantes de la zone 10, le systeme 
d' exploitation 7, comportant un programme appelg moteur de 
verification 9, exploite une table des transitions 11 qui 
permet de preciser les etats auxquels on peut acceder a 
partir de l'etat courant, une table des verifications 12 
qui permet d'associer a chaque transition d'etat des 
verifications portant sur le contenu des memoires 3, 4 
et/ou 5. Dans une variante, le moteur de verification 9 
peut declencher automat iquement des actions lors du 
franchissement ou du rejet du f ranchissement d'une 
transition. Pour cela la zone 10 de la memoire de programme 
comporte une table des actions 13 qui permet d'associer a 
chaque transition d'etat possible des actions a effectuer. 

Une memoire volatile 3 (ou encore RAM pour Random 
Access Memory en langue anglaise) permet a l'unit<§ de 
traitement 2 de stocker de maniere temporaire des resultats 
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ou encore des secrets issus de calculs decrits par les 
programmes implantes dans la memoire de programme 4 . Le 
contenu de la memoire 3 est efface a chaque mise sous 
tension du composant 1 ou a chaque demande de remise a zero 
de celui-ci. 

Une memoire de donnees 5, effagable electriquement 
utilisant generalement la technologie EEPROM (pour 
Electrical Erasable Programmable Read Only Memory en langue 
anglaise) comporte une zone 14 contenant les donnees 
variables necessaires a 1' execution des programmes 7. Cette 
zone 14 comporte notamment une donnee 8 appelee "Etat 
courant" permettant de mernoriser 1 1 etat courant de l'objet 
electronique portatif. La memoire de donnees 5 comporte en 
outre une zone 15 comprenant optionnellement des extensions 
des tables 11 a 13 dans le cas ou il est necessaire 
d'aj outer des etats aux etats de references. La zone 15 
comporte alors une extension de la table des transitions 
16, une extension de la table des verifications 17 et peut 
comporter une. extension de la table des actions 18 si l f on 
souhaite associer aux nouvelles transitions d'etat additif 
des actions, corarne vu precedemment pour ce qui concerne la 
table 13. Dans le cas d'ajout d' etats par rapport aux etats 
de reference, il est parfois indispensable d'enrichir le 
systeme d ! exploitation 7. Pour cela, la memoire 5 peut 
comporter en outre une zone 19 qui contient les programmes 
supplement aires qui seront executes a leur tour par l'unit<S 
de traitement 2 . 

La figure 2a montre une mise en oeuvre possible de la 
table des transitions 11. Si 1 ■ on suppose que 1 " on denombre 
i etats de reference, on peut imaginer une table de 
transition comprenant i colormes et i lignes. Les colonnes 
correspondent aux etats de reference pouvant etre, a un 
instant donne, 1 1 etat courant. Les i premieres lignes 
correspondent aux etats de reference auxquels on peut 



FEUILLE MODIFI E 



27-1 2-2000 FR 009902678 



10 



acceder a partir de l'etat courant. Ainsi la valeur d'une 
case de la table des transitions 11 correspondant a 
1 1 intersection d'une ligne et d ! une colonne de ladite table 
permet de coder soit, 1 1 absence de transition autorisee 
5 (valeur nulle par exemple - c • est le cas de la transition 
20), soit, 1 1 autorisation une transition (valeur non nulle 
- c'est le cas de la transition 21). Dans le cas d'une 
transition autorisee, le moteur de verification de 
transitions recherche au sein de la table de verification 
10 12 les verifications a effectuer pour accepter ou rejeter 
le f ranchissement de la transition demandee. 

La figure 2b montre egalement une mise en oeuvre 
possible d'une table de transition dans le cas ou il est 
15 possible d f aj outer des etats (etats additifs) aux etats de 
reference.. La table des transitions comporte une ligne 
supplementaire par rapport a la figure 2a. La (i+l)eme 
ligne permet de preciser si 1 1 on autorise des transitions 
d f un etat de reference courant a un etat additif. Ainsi la 

2 0 valeur de la case 22 indique une transition interdite d'un 

etat de reference vers un etat additif. La case 23 indique 
qu'il sera possible de basculer de 1 1 etat de reference Ei 
vers un etat additif. Une extension 16 de la table des 
transitions est alors necessaire. Cette derniere comporte j 
25 lignes correspondant a j etats additifs auxquels on peut 
acceder a partir de (i+j) etats courant possibles 
materialises par les (i+j) colonnes de 1' extension 16 de la 
table des transitions. Ainsi la combinaison de la case 23 
de la table des transitions et de la case 24 de 1' extension 

3 0 16 de la table des transitions, indique au moteur de 

verification qu'il est possible de basculer de l'etat de 
reference Ei vers l'etat additif E(i+1) . 

La figure 3 montre une mise en oeuvre de la table des 
35 verifications. La table des verifications 12 est implantee 
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au sein de la zone 10 des donnees predefinies de la memoire 
4. Chaque transition autorisee dispose d'une entree dans 
ladite table. Une entree comprend un champ 3 0 permettant 
d ! identifier la transition et un champ 31 contenant une 
reference (ou adresse) vers un programme 32 du systeme 
d 1 exploitation 7. Le moteur de verification 9 peut ainsi 
f aire executer a 1 ' unite de traitement 2 les controles 
requis pour accepter le f ranchissement de la transition. La 
figure 3 illustre egalement une structure d'une extension 
17 de la table des verifications. De la meme maniere que 
pour la table 12, 1 ! extension de la table des verifications 
17 comporte une entree par transition possible. Chaque 
entree comprend deux champs, un champ 33 permettant 
d* identifier la transition et un champ 34 contenant une 
reference (ou adresse) d f un programme 35 du systeme 
d l exploitation ou, comme le montre la figure 3, d'un 
programme supplement aire implante dans la memoire de 
donnees 5 (en zone 19) . 

La figure 4 montre une representation de la table des 
actions 13 implantee dans la zone 10 des donnees 
predefinies de la memoire de programmes 4. Lors d'une 
demande de f ranchissement de transition, il est possible de 
declencher des actions. Celles-ci peuvent etre de trois 
types: action systematique, action positive (c'est a dire 
conditionnee au fait que les verifications sont 
satisf aisantes) ou action negative (c'est a dire 
conditionnee au fait que les verifications ne sont pas 
satisf aisantes) . La figure 4 montre qu ' a chaque transition 
autorisee, il existe une entree dans la table des actions 
13. Cette entree comprend 4 champs. Le premier champ 400 
permet d 1 identifier la transition. Les trois autres champs 
401, 402 et 403 contiennent chacun une reference ou adresse 
d'un programme 4 04, 40 5 ou 4 06 du systeme d' exploitation. 
Le champ 401 est dedie a une action systematique, le champ 
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4 02 a une action positive et le champ 403 a une action 
negative. La figure 4 montre egalement une extension 18 de 
la table des actions. Cette table 18 est implantee dans la 
zone 15 de la memoire de donnees 5 du composant 1. De la 
5 meme maniere que pour la table des actions 13 , l 1 extension 
de la table des actions 18 comprend une entree par 
transition possible. Une entree comprend 4 champs. Le 
premier champ 407 permet d ! identifier la transition. Les 
trois autres champs 408, 409 et 410 contiennent chacun une 

10 reference ou adresse d*un programme 411, 412 ou 413 du 
systeme d * exploitation ou comme le montre la figure 4, des 
programmes implantes dans la zone 19 de la memoire de 
donnees 5 du composant 1. Le champ 408 est dedie a une 
action systematique , le champ 409 a une action positive et 

15 le champ 410 a une action negative. 

La figure 5a decrit le procede permettant de valider ou 
de rejeter le f ranchissement d'une transition d'etat, d f un 
premier etat de reference vers un autre etat de reference. 

20 La demande de f ranchissement d'une transition peut etre 
formulee suite a un ordre du fabricant de carte ou par tout 
autre acteur du cycle de vie de la carte a puce. Ladite 
demande peut egalement etre formulee directement par la 
carte-elle meme, par exemple au travers d'une action 

25 associee a une transition. Dans le cadre de la figure 5a, 
1 ' etat de reference courant est 1 1 etat Ei. L'ordre 50 de 
basculement de 1 ' etat Ei a 1 1 etat Ej est formule. L'etape 
51 consiste a verifier au sein de la table des transitions 
11 que la transition de 1 1 etat Ei vers 1 ' etat Ej est 

3 0 autorisee. Dans le cas ou cette transition est interdite, 
la demande de f ranchissement de transition 50 est rejetee. 
L'etat courant demeure l'etat Ei . Par contre, si la 
transition est autorisee, le moteur de verification 9 
execute les verifications associees a ladite transition. 

35 Pour cela le moteur de verification evalue l 1 entree de la 
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table des verifications 12 dediee a la transition T (Ei- 
>E j ) . L 1 execution desdites verifications correspond a 
1' etape 52 du procede. Le moteur de verification 9 execute 
les actions systematiques associees a la transition T (Ei- 
>Ej) en fonction de 1 1 entree de la table des actions 13 
dediees & ladite transition (etape 53). Si les 
verifications 54 exigees lors de la demande de 
f ranchissement de la transition 50 sont non satisf aisantes, 
I 1 etat courant demeure inchange. En fonction de 1 1 entree de 
la table des actions 13 associee a la transition T(Ei->Ej) 
le moteur de verifications execute les actions negatives 
(etape 55 du procede) . Le deroulement du procede est alors 
termine. Par contre, si les verifications 54 sont 
satisf aisantes , alors l'etat courant devient l'etat Ej 
(etape 56 du procede) . Les actions positives sont alors 
executees (etape 57 du procede) en fonction de l'etat de 
l 1 entree de la table des actions 13 associee a la 
transition T(Ei->Ej). Le deroulement du procede est 
termine . 

La figure 5b decrit le procede permettant de valider ou 
de rejeter le f ranchissement d'une transition d'etat, d'un 
premier etat additif vers un autre etat additif . L'etat 
additif courant est 1 ■ etat Ei . L ' ordre 510 de basculer de 
l'etat additif Ei a l'etat additif (ou de reference) Ej est 
formule. L 1 etape 511 du procede consiste a verifier au 
sein de 1' extension la table des transitions 16 que la 
transition de I'etat Ei a l'etat Ej est autorisee. Dans le 
cas ou cette transition est interdite, la demande de 
f ranchissement de transition 510 est rejetee. L ! etat 
courant demeure l ! etat Ei. Par contre, si la transition est 
autorisee, le moteur de verification 9 execute les 
verifications associees a ladite transition. Pour cela, le 
moteur de verification evalue 1 1 entree de 1 ' extension de la 
table des verifications 17 dediee a la transition T (Ei- 
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>Ej ) . L ' execution desdites verifications constitue 1 1 etape 
512 du procede. Le moteur de verification 9 execute les 
actions systematiques associees a la transition T (Ei->Ej ) 
en fonction de 1 1 entree de 1' extension de la table des 
5 actions 18 dediees a ladite transition (etape 513 du 
procede) . Si la verification 514 exigee lors de la demande 
de franchissement de la transition 510 est non 
satisf aisante, l'etat courant demeure inchange. En fonction 
de l 1 entree de 1' extension de la table des actions 18 

10 associee a la transition T(Ei->Ej), le moteur de 
verification 9 execute les actions negatives (etape 515 du 
procede) . Le deroulement du procede est alors termine. Par 
contre, si les verifications 514 sont satisf aisantes , 
l'etat courant devient 1 1 etat Ej (etape 516 du procede). 

15 Les actions positives sont alors executees (etape 517 du 
procede) en fonction de l'etat de 1 1 entree de 1 1 extension 
de la table des actions 18 associee a la transition T(Ei- 
>E j ) . Le deroulement du procede est termine. 

20 La figure 5c decrit le procede permettant de valider ou 

de rejeter le franchissement d'une transition d'etat, d'un 
etat de reference vers un etat additif . L'etat de reference 
courant est l'etat Ei. L 1 ordre 520 de basculement de l'etat 
de reference Ei a l'etat additif Ej est formule. L 1 etape 

25 528 du procede consiste a verifier au sein de la table des 
transitions 11, qu'une transition de l'etat de reference 
courant Ei vers un etat additif est autorisee. Si une telle 
transition est interdite, le procede est termine. L'etat 
courant demeure inchange. Par contre, si une transition 

30 dudit etat de reference vers un etat additif est autorisee, 
le moteur de verification deroule les etapes 521 a 527 du 
procede, respectivement identiques aux etapes 511 a 517 
decrites en liaison avec la figure 5b. 



FEUILLE MODIFI E 



27-12-2000 



FR 009902678 



15 



Un exemple d ' application dans le domaine du Porte- 
monnaie electronique est presente en liaison avec les 
figures 6a a 6d. Ladite application permet de regler des 
achats a 1 1 aide "d 1 argent electronique" stocke dans une 
5 carte a puce, au lieu de payer en numeraire. L'emploi d'une 
telle technique impose une gestion des cartes aussi 
securisee que celle qu'aurait impose l'emploi du numeraire, 
II faut par exemple eviter la creation de monnaie fictive. 
La securite d'une carte a puce porte-monnaie electronique 

10 repose generalement sur des cles stockees a l'interieur de 
ladite carte a puce permettant des transactions securisees 
en utilisant la cryptographie . Une telle carte dispose d'un 
systeme d 1 exploitation off rant un jeu de commandes et de 
services permettant de crediter ou de debiter de I 7 argent. 

15 Au debut du cycle de vie de la carte a puce porte-monnaie 
electronique, ladite carte a puce n'est pas initialisee. 
Elle ne contient aucune information. La figure 6a montre 
les etats de reference predefinis : 

- Etat El "carte vierge" (reference 80) : seules des 

2 0 commandes de test permettant de valider le comportement de 

la memoire de donnees 5 sont disponibles (verification que 
les cases memoires de technologie EE PROM peuvent etre 
correctement ecrites et effacees) ; 

- Etat E2 "carte testee" (reference 82) : Les commandes 
25 de test ne sont plus disponibles. A leur tour des commandes 

dites generalement "commandes physiques" (permettant un 
acces en ecriture par un adressage physique independamment 
de toute structure logique de type fichier par exemple) 
sont disponibles. Elles permettent d' initialiser la carte 

3 0 (ecriture dans la zone 14 de la memoire de donnees des 

constituants logiques necessaires au f onctionnement de 
1 'application c 1 est a dire fichiers, balances...); 

Etat E3 "carte initialisee" (reference 84) : les 
commandes physiques ne sont plus disponibles . Des commandes 
35 logiques permettent de personnaliser la carte (ajout de 
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nouvelles structures logigues et initialisation de donnees 
dans lesdites structures) sont utilisables. En outre, un 
mecanisme de recouvrement est active de sorte que la carte 
a puce ne perde pas la coherence de ces donnees lors d 1 une 
mise hors tension de celle-ci durant 1' execution de I'une 
desdites commandes logiques. 

- Etat E4 "carte persormalisee" (reference 86) : les 
commandes logiques specif iques a 1 1 application Porte- 
monnaie electronigue (debit/credit) sont activees. 

Le jeu de commandes disponibles evolue en fonction de 
ligtape de vie dans laquelle se trouve la carte a puce. Des 
informations stockees en memoire de donnees permettent au 
systeme d' exploitation de connaitre l'etat dans lequel la 
carte a puce se trouve. La figure 6a montre en outre que 
dans le cadre d ! une carte de type porte-monnaie 
electronique, toutes les transitions entre etats de 
reference doivent etre franchies success ivement (de l'etat 
El a l'etat E4) et ce de maniere irreversible. Toute autre 
transition est interdite. Seule la possibility d f utiliser 
ulterieurement des etats additifs 88 est offerte. Cette 
transition possible est referencee 87. Le systeme 
d ! exploitation en fonction de l'etat courant n'autorise 
qu'un ensemble de commandes specif iques a chaque etat de 
reference . 

Les verifications et les actions a declencher lors du 
f ranchissement d'une transition sont decrites comme suit : 
Transition de l'etat El vers l'etat E2 (notee 
T(E1->E2) et referencee 81) : 

- Verification: aucune 

- Action sys t etna ti que : 

effacement de la memoire de donnees pour 
eviter qu'un fraudeur y laisse des donnees 
interpretables par le systeme 

d 7 exploitation de la carte; 
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- Transition de l'etat E2 vers l'etat E3 (notee 
T(E2->E3) et referencee 83) : 

- Verification: 

- integrite des donnees ecrites dans la 
memoire de donnees avec les commandes 
physiques (validation d'un code de 
redondance par donnee) ; 

- verification de l'etat vierge de la 
memoire en dehors desdites donnees ; 

- Action positive : 

- activation du mecanisme de recouvrement; 

- Transition de l'etat E3 vers l'etat E4 (notee 
T(E3->E4) et referencee 85) : 

- Verification: 

- nullite de la balance du porte monnaie 
electronique 

- Action : aucune 

- Transition de l'etat E4 vers un etat additif (notee 
T(E4->Eadd) et referencee 87) : 

- Verification : aucune 

- Action : aucune 

Les figures 6b a 6d illustrent respect ivement une 
realisation d'une table des transitions 11, d'une table des 
verifications 12 et d'une table d' actions 13, selon 
1' invention. La table des transitions 11 telle que decrite 
en liaison avec la figure 6b permet de n'autoriser que les 
transitions 81, 83, 85 et 87. Pour cela seules les cases 60 
a 63 de ladite table contiennent une valeur non nulle. Les 
autres cases de la table des transitions contiennent une 
valeur nulle pour indiquer que toute autre transition est 
interdite. La table des verifications telle que presentee 
au travers de la figure 6c, permet d'associer les 
verifications a satisfaire pour autoriser le f ranchissement 
des transitions 81, 83, 85 et 87, lesdites transitions 
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autorisees par la table des transitions 11 (figure 6b) . 
Ainsi 1' entree 64 de la table des verifications 12 comporte 
un champ 641 permettant d 1 identifier que ladite entree est 
dediee k la transition 81. L 1 entree 64 comporte en outre un 
5 champ 642 contenant une reference nulle pour indiquer 
qu'aucune verification n'est demandee pour autoriser le 
f ranchissement de la transition 81. Dans une variante, la 
transition 81 ne dispose d ' aucune entree associee. Cette 
variante est illustree plus loin dans le cas de la table 

10 des actions. La table des verifications 12 comporte une 
entree 65 qui comprend respect ivement un champ 651 pour 
indiquer que 1 1 entree est associee a la transition 83 et un 
champ 652 contenant la reference d'un programme 67, 
implante dans la memoire de programmes, pour que le moteur 

15 de verification puisse effectuer les verifications decrites 
precedemment. De meme, la table des verifications 12 
comporte une entree 66 qui comprend respect ivement un champ 
661 pour indiquer que l f entree est associee a la transition 
83 et un champ 662 contenant la reference d'un programme 

2 0 68, implante dans la memoire de programmes, pour que le 
moteur de verification puisse effectuer les verifications 
decrites precedemment . 

La figure 6d presente une realisation de la table des 
2 5 actions 13. Ladite table comporte une entree 71 qui 
comporte un champ 711 permettant d» indiquer que ladite 
entree est associee a la transition 81. La meme entree 71 
comporte un champ 712 contenant la reference d f un programme 
75, implante dans la memoire de programmes, afin que le 
, 3 0 moteur de verification puisse executer les actions 
systematiques associees a la transition 81. L' entree 71 
comporte en outre un champ 713 et un champ 714 contenant 
une reference nulle pour indiquer au moteur de verification 
qu'aucune action positive ni negative n'est associee au 
35 f ranchissement de la transition 81. De la meme maniere, la 
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table des actions 13 comport e une seconde entree 72 
comprenant les champs 721 a 724 pour indiquer au moteur de 
verification que ladite entree est associee a la transition 
83, que le programme 74 est a executer comme action 
5 positive lors du f ranchissement de ladite transition et 
qu'aucune action systematique ou negative n'est a executer. 
L 1 absence d f entree, au sein de la table des actions 13, 
associee a la transition 85, indique qu'aucune action 
(systematique, positive ou negative) n'est a executer lors 
10 du f ranchissement ou du re jet du f ranchissement de ladite 
transition. 

Grace au dispositif et au procede tels que decrits ci- 
dessus, le cycle de vie d'un objet electronique portatif 

15 est maitrise. Chaque transition d'etats est irreversible et 
les verifications faites lors de chaque demande de 
transitions garantissent une configuration memoire de 
1 'objet coherente. En outre les actions systematiques , 
positives ou negatives permettent d' adapter le comportement 

20 dudit objet. Enfin, dans le cas ou il est prevu d'autoriser 
une ou plusieurs transitions d f un ou plusieurs etats de 
reference vers un etat additif, le cycle de vie de 1' objet 
peut etre facilement enrichi, par exemple apres que l 1 objet 
soit emis sur le marche, sans que le cycle de vie predefini 

25 (compose par une succession de transitions d'etat de 
reference vers un autre etat de reference) puisse etre 
detourne . 

Tout risque de fraude durant 1 ■ initialisation d'un 
objet electronique portatif ou d'erreur malencontreuse 
3 0 durant ladite initialisation est ecarte tout en conservant 
grande adaptability du controle du cycle de vie de l f objet. 
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REVINDICATIONS 



1. Dispositif de contrdle du cycle de vie d'un objet' 
electronique portatif, le cycle de vie etant determine par 
une succession de transitions d'etats, lesdits etats 
determinant les services offerts par 1' objet, ledit objet 
5 comprenant une unite de traitement (2), une memoire volatile 
(3), des memoires de programmes (4) et des memoires de 
donnees (5), chacune de ces memoires (3, 4, 5) presentant un 
contenu definissant une pluralite de configurations, 

caracterise en ce qu'il comporte des moyens de controle 
10 de la transition d'un premier etat a un second etat de 
l'objet electronique portatif, exploitant des moyens 
d' autorisation et/ou interdiction de transitions d'etat, de 
sorte que seules certaines transitions ne soient permises 
parmi 1' ensemble des transitions possibles. 



15 



20 



25 



30 



2. Dispositif selon la revendication 1, caracterise en ce 
que les moyens de contr61e comprennent des moyens de 
verification du contenu de la memoire volatile (3) , des 
memoires de donnSes (5) et des memoires de programmes (4) de 
l'objet electronique portatif, en fonction de la transition 
d'etats permise a effectuer. 

3. Dispositif selon l'une quelconque des revendi cat ions 1 
ou 2, caracterise en ce que les moyens de controle autorisent 
et/ou interdisent une transition d'etat en exploitant une 
table (11) des transitions d'etat permises. 

4. Dispositif selon la revendication 3, caracterise en ce 
que les moyens de contr61e comprennent : 

- outre la table (11) des transitions d'etat permises; 

- une table (12) des verifications a effectuer par 
transition d'etat permise; 

- et un moteur de verification (9) exploitant lesdites 
tables . 
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5. Dispositif selon la revendication 3, caracterise en 
ce que les moyens de controle de la transition d f un premier 
etat a un second etat de I'objet electronique portatif 

5 comprennent : 

- une extension (16) de la table (11) des transitions 
d'etat permises; 

6. Dispositif selon la revendication 4, caracterise en ce 
que les moyens de controle de la transition d ! un premier etat 
a un second etat de I'objet electronique portatif 
comprennent : 

- une extension (16) de la table (11) des transitions 
d'etat permises; 

- une extension (17) de la table (12) des verifications a 
effectuer par transition d'etat permise; 

et en ce que le moteur de verification (9) exploite 
lesdites extensions de tables (16, 17) . 

7. Dispositif selon I'une quelconque des revendications 1 
a 6, caracterise en ce que les moyens de controle comprennent 
des moyens perraettant de declencher des actions lors du 
traitement d'une demande de f ranchissement de transition d'un 
premier etat a un second etat de l'objet electronique 
portatif . 

8. Dispositif selon la revendication 7 lorsque celle-ci 
depend des revendications 5 ou 6, caracterise en ce que les 
moyens permettant de declencher des actions lors du 
traitement d'une demande de f ranchissement de transition d'un 
premier etat a un second etat de l'objet electronique 
portatif, comprennent une table (13) d' actions exploitable 
par le moteur de verification (9) . 
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9. Dispositif selon la revendication 8, caracterise en ce 
que les moyens permettant de declencher des actions lors du 
traitement d'une demande de f ranchis semen t de transition d'un 
premier etat a un second etat de 1' objet electronique 

5 portatif, comprennent une extension (18) de la table (13) 
d' actions exploitable par le moteur de verification (9) . 

10. Objet electronique portatif, comportant une unite de 
traitement (2) , une memoire volatile (3) , des memoires de 

10 programmes (4) et des memoires de donnees (5) , caracterise en 
ce qu'il comporte le dispositif de controle du cycle de vie 
de l'objet, selon l'une des revendications 1 a 9. 

11. Carte a puce, comportant une unite de traitement (2)/ 
15 une memoire volatile (3) , des memoires de programmes (4) et 

des memoires de donnees (5) , caracterise en ce quelle 
comporte le dispositif de controle du cycle de vie de la 
carte, selon l'une des revendications 1 a 9. 

2 0 12. Procede de controle du cycle de vie d'un objet 

electronique portatif, le cycle de vie etant determine par 
une succession de transitions d'etats, lesdits etats 
determinant les services offerts par l'objet, ledit objet 
comprenant une unite de traitement (2) , une memoire volatile 

25 (3), des memoires de programmes (4) et des memoires de 
donnees (5), chacune de ces memoires (3, 4, 5) presentant un 
contenu definissant une pluralite de configurations, 

ledit procede etant mis en oeuvre, au sein de l'objet, a 
la suite d'une demande de transition d'etats, 

30 caracterise en qu'il comprend : 

- une etape (51, 511, 528, 521) de validation de 
1 ' autorisation de ladite demande en exploitant des moyens 
d' autorisation et/ou interdiction de transitions d'etat, de 
sorte que seules certaines transitions ne soient permises 

35 parmi 1' ensemble des transitions possibles; 
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- une etape (57, 517, 527) de modification de 1 r etat 
courant de l'objet si la transition demandee est autorisee 
(51, 511, 528, 521) . 

5 13. Procede selon la revendication 12, caracterise en ce 

qu'il comprend une etape (53, 513, 523) d' execution d 1 actions 
systematiques, actions associees a la transition demandee, 

14. Procede selon l'une quelconque des revendications 12 
10 ou 13, caracterise en ce qu'il comprend : 

- une etape (52, 512, 522) devaluation des verifications 
de la configuration de l'objet, verifications associees a une 
transition permise; 

- et en ce que 1' etape (57, 517, 527) de modification de 
15 l'etat courant de l'objet, est realisee si lesdites 

verifications de la configuration de l'objet sont satisfaites 
(54, 514, 524) . 

15. Procede selon la revendication 14, caracterise en ce 
20 qu'il comprend line etape (56, 516, 526) d 1 execution d'actions 

positives, realisee si la transition demandee est permise 
(51, 511, 528, 521) , et si les verifications associees £ la 
transition demandee sont satisfaites (54, 514, 524) . 

25 16. Procede selon I'une quelconque des revendications 14 

ou 15, caracterise en ce qu'il comprend une etape (55, 515, 

525) d' execution d'actions negatives si les verifications 
associees a la transition demandee ne sont pas satisfaites 
(54, 514, 524) . 

30 

17. Procede selon l'une quelconque des revendications 12 
a 13, caracterise en ce qu'il comprend une etape (56, 516, 

526) d' execution d'actions positives realisee si la 
transition demandee est permise (51, 511, 528, 521) . - 

35 
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18. Procede selon l'une quelconque des revendications 12 
a 17, mis en oeuvre au sein de l'objet, a la suite d'une 
demande de transition d'un premier etat de reference vers un 
second etat de reference, caracterise en que l'etape (51) de 

5 validation de 1 1 autorisation de ladite demande consiste a 
analyser une table (11) des transitions permises. 

19. Procede selon la revendication 18 , lorsque celle-ci 
depend des revendications 13 a 17, caracterise en ce que 

10 l'etape (53) d 1 execution d 1 actions systematiques consiste : 

- a exploiter une entree (400, 401) , correspondant a la 
transition demandee, d ! une table (13) d' actions et ; 

a executer un programme d' actions (404) defini par 
ladite entree. 

15 

20. Procede selon l'une quelconque des revendications 18 
ou 19, lorsque la revendication 18 depend des revendications 

14 a 16, caracterise en ce que l'etape (52) d* evaluation des 
verifications associees a la transition demandee, consiste : 

2 0 a exploiter une entree (3 0) d'une table (12) des 

verifications et ; 

- a executer un programme (32) de verifications defini 
par ladite entree. 

25 21. Procede selon l'une quelconque des revendications 18 

a 20, lorsque la revendication 18 depend des revendications 

15 a 16 , caracterise en ce que l'etape (56) d 1 execution 
d 1 actions positives consiste, si la transition demandee est 
autorisee (51) et si les verifications associees a la 

3 0 transition demandee sont satisfaites (54) : 

- a exploiter une entree (400, 402), correspondant a la 
transition demandee, d'une table (13) d' actions et ; 

a executer un programme (405) d' actions defini par 
ladite entree. 

35 
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22. Procede selon l'une quelconque des revendi cat ions 18 
a 21, lorsque la revendication 18 depend de la revendication 

16, caracterise en ce que 1 ' etape (55) d' execution dictions 
negatives consiste, si les verifications associees a la 

5 transition demandee ne sont pas satisfaites (54) : 

- a exploiter une entree (400, 403), correspondant a la 
transition demandee, de la table (13) d 1 actions et ; 

- a ex6cuter un programme (406) d' actions defini par 
ladite entree . 

10 

23. Procede selon l'une quelconque des revendications 18 
a 19, lorsque la revendication 18 depend de la revendication 

17, caracterise en ce que 1' etape (56) d' execution d' actions 
positives consiste, si la transition demandee est autorisee 

15 (51) : 

- a exploiter une entree (400, 4 02) , correspondant a la 
transition demandee, d'une table (13) d' actions et ; 

- a executer un programme (4 05) d' actions defini par 
ladite entree. 

20 

24. Procede selon l'une quelconque des revendications 12 
a 17, mis en oeuvre au sein de l ! objet, a la suite d'une 
demande de transition d'un premier etat additif vers un 
second etat additif, caracterise en que 1' etape (511) de 

25 validation de 1 1 autorisation de ladite demande consiste a 
analyser une extension (16) d'une table (11) des transitions 
permises . 

25. Procede. selon la revendication 24, lorsque celle-ci 
30 depend des revendications 13 a 17, caracterise en ce que 

1' etape (513) d 1 execution d' actions systematiques consiste : 

- a exploiter une entree (407, 408), correspondant a la 
transition demandee, d'une extension (18) d'une table (13) 
d' actions et ; 
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- a executer un programme d' actions (411) defini par 
ladite entree . 

26. Procede selon 1'une quelconque des revendications 24 
5 ou 25/ lorsque la revendication 24 depend des revendications 

14 a 16, caracterise en ce que l'etape (512) devaluation des 
verifications associees a la transition demandee consiste : 

- a exploiter une entree (3 3) d'une extension (17) d'une 
table (12) des verifications et ; 

10 - a executer un programme (35) de verifications defini 

par ladite entree. 

27. Procede selon 1'une quelconque des revendications 24 
a 26, lorsque la revendication 24 depend des revendications 

15 15 a 16, caracterise en ce que l'etape (516) d' execution 
d 1 actions positives consiste, si la transition demandee est 
autorisee (511) et si les verifications associees a la 
transition demandee sont satisfaites (514) : 

- a exploiter une entree (407, 409) , correspondant a la 
20 transition demandee, d'une extension (18) d'une table (13) 

d' actions et ; 

a executer un programme d' actions (412) defini par 
ladite entree. 

25 28. Procede selon l'une quelconque des revendications 24 

a 27, lorsque la revendication 24 depend de la revendication 
16, caracterise en ce que l'etape (515) d ! execution d 1 actions 
negatives consiste, si les verifications associees a la 
transition demandee ne sont pas satisfaites (514) : 

3 0 - a exploiter une entree (407, 410) , correspondant a la 

transition demandee, d'une extension (18) d'une table (13) 
d' actions et ; 

- a executer un programme d' actions (413) defini par 
ladite entree. 

35 
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29. Procgde selon l'une quelconque des revendications 24 
a 2 5, lorsque la revendication 24 depend de la revendication 
17, caracterise en ce que 1 ' etape (516) d'execution d'actions 
positives consiste, si la transition demandee est autorisee 

5 (511) : 

- a exploiter une entree (407, 409), correspondant a la 
transition demandee, d'une extension (18) d'une table (13) 
d 1 actions et ; 

- a executer un programme d' actions (412) defini par 
10 ladite entree. 

30. Procede selon l'une quelconque des revendications 12 
a 17, mis en osuvre au sein de l'objet, a la suite d'une 
demande de transition d'un etat de reference vers un etat 

15 additif, caracterise en que 1' etape (528, 521) de validation 
de 1 'autorisation de ladite demande consiste a : 

- valider (528) 1 • autorisation d'une transition dudit 
etat de reference vers un etat additif en analysant une table 
(11) des transitions permises; 

20 " valider (521) 1 ' autorisation d'une transition dudit 

etat de reference vers ledit etat additif en analysant une 
extension (16) de la table (11) des transitions permises. 



25 



30 



31. Procede selon la revendication 30, lorsque celle-ci 
depend des revendications 13 a 17, caracterise en ce que 
1' etape (513) d'execution d' actions systematiques consiste : 

- a exploiter une entree (407, 408), correspondant a la 
transition demandee, d'une extension (18) d'une table (13) 
d' actions et ; 

- a executer un programme d' actions (411) defini par 
ladite entree. 

32. Procede selon l'une quelconque des revendications 3 0 
ou 31, lorsque la revendication 30 depend des revendications 
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14 a 16, caracterise en ce que 1'etape (522) devaluation des 
verifications associees a la transition demandee consiste : 

- k exploiter une entree (33) d'une extension (17) d'une 
table (12) des verifications et ; 

5 - a executer un programme (35) de verifications defini 

par ladite entree. 

33. Procede selon l'une quelconque des revendications 30 
a 32 , lorsque la revendication 30 depend des revendications 
10 15 a 16, caracterise en ce que 1'etape (526) d' execution 
d» actions positives consiste, si la transition demandee est 
autorisee (528, 521) et si les verifications associees a la 
transition demandee sont satisfaites (524) : 

- a exploiter une entree (407, 409), correspondant a la 
15 transition demandee, d'une extension (18) d'une table (13) 

d f actions et ; 

- a executer un programme d' actions (412) defini par 
ladite entree . 

20 34. Procede selon l'une quelconque des revendications 30 

a 33, lorsque la revendication 30 depend de la revendication 

16, caracterise en ce que 1'etape (525) d'execution d'actions 
negatives consiste, si les verifications associees a la 
transition demandee ne sont pas satisfaites (524) : 

25 " ^ exploiter une entree (407, 410), correspondant a la 

transition demandee, d'une extension (18) d'une table (13) 
d'actions et ; 

- a executer un programme d'actions (413) defini par 
ladite entree . 

30 

35. Procede selon l'une quelconque des revendications 30 
a 31, lorsque la revendication 30 depend de la revendication 

17, caracterise en ce que 1'etape (526) d'execution d'actions 
positives consiste si la transition demandee est autorisee 

35 (528, 521) : 
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- a exploiter une entree (407, 409), correspondant a la 
transition demandee, d'une extension (18) d'une table (13) 
d ! actions et ; 

- a executer un programme d' actions (412) defini par 
5 ladite entree. 

36. Procede selon l'une quelconque des revendi cat ions 12 
a 35, caract^rise en ce que ledit procede n'autorise pas le 
franchissement d'une transition d'etat, d'un etat additif 
10 vers un etat de reference. 
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1 . Base du rapport 

a. En ce qui concerne la langue, la recherche internationale a et6 effectuee sur la base de la demande Internationale dans la 
langue dans laquelle elle a et6 deposed, sauf indication contraire donnee sous le meme point 

| | la recherche internationale a 6t6 effectuee sur la base d'une traduction de la demande internationale remise a radministration. 

b. En ce qui concerne les sdquences de nucleotides ou d'acides amines divulguees dans la demande internationale (le cas echeant), 
la recherche Internationale a effectuee sur la base du listage des sequences : 

contenu dans la demande internationale. sous forme 6c rite, 
dgposee avec la demande internationale, sous forme dechiffrable par ordinateur. 
remis ulterieurement a {'administration, sous forme gcrite. 
rem is ulterieurement a radministration, sous forme dechiffrable par ordinateur. 

La declaration, selon laquelle le listage des sequences presents' par ecrit et fourni ulterieurement ne vas pas au-dela de la 
divulgation faite dans la demande telle que d£posee, a ete fournie. 

La declaration, selon laquelle les informations enregistrees sous forme dechiffrable par ordinateur sont identiques a celles 
du listage des sequences presents par ecrit, a ate fournie. 

II a etc" estime que certaines revendications ne pouvalent pas fa ire I'objet d'une recherche (voir le cadre I). 
II y a absence d'unite de ('Invention (voir le cadre II). 



□ 
□ 
□ 
□ 
□ 

□ 

a □ 



En ce qui concerne le titre, 

[X] le texte est approuv6 tel qu'il a 6t6 remis par le deposant. 

| | Le texte a et6 6tabli par ('administration et a !a teneur suivante: 



5. En ce qui concerne I'abrege, 

[ | le texte est approuve tel qu'il a etd remis par le deposant 

Ele texte (reproduit dans le cadre III) a et$ etabli par radministration conformement a la regie 38.2b). Le deposant peut 
presenter des observations a i'administration dans un delai d'un mois a compter de la date d'exp^dition du present rapport 
de recherche internationale. 

6. La figure des dessins a publier avec I'abregd est la Figure n° J 

[X[ suggSree par le deposant. ["H Aucune des figures 

rn , * . aa^ v n'est a publier. 

| | parce que le deposant n'a pas sugger^ de figure. 

| | parce que cette figure caracterise mieux rinvention. 



Formulaire PCT/ISA/210 (premiere feuille) (juiilet 1998) 





Demande Internationale n° 




RAPPORT DE RECHERCHE INTERNATIONALE 


PCT/FR 99/02678 





Cadre III TEXTE DE L'ABREGE (suite du point 5 de la pr mi ere feullle) 



L'abrege doit etre modifie comme suit: 

ligne 3: apres 'puce' inserez '(1)'; 

ligne 6: apres 'traitement' inserez '(2)'; 

ligne 6: apres 'programmes' inserez '(4)'; 

ligne 7: apres 'donnees' inserez '(5)'; 

ligne 9: apres 'controle' inserez '(9, 11, 12). 
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A. CLASSEMENT DE L'OBJET DE LA DEMANDE 

CIB 7 G06K19/073 G07F7/10 



Selon la classification Internationale des brevets (CIB) ou a ta fols selon la classification national© et la CIB 



B. DOMAINES SUR LESQUELS LA RECHERCHE A PORTE 



Documentation mintmale consultee (systeme de classification suivi des symboles de classement) 

CIB 7 G06K G07F 



Documentation consultee autre qua ta documentation mlntmaie dans la mssure ou ces documents relevant des domaines sur las quels a porta la recherche 



Base de donnees electronlque consultee au cours de (a recherche Internationale (nom de la base de donnees, et si realisable, termes de recherche utilises) 



C. DOCUMENTS CONSIDERES COMME PERTINENTS 



Categorie ° Identification des documents cites, avec, le cas echeant, I'indication des passages pertinents 



no. des revendlcatfons vlsees 



US 5 473 690 A (GRIMONPREZ GEORGES ET AL) 
5 decembre 1995 (1995-12-05) 
le document en entier 

WO 98 09257 A (GEMPLUS CARD INT) 

5 mars 1998 (1998-03-05) 

page 14, ligne 4 -page 20, ligne 19 

EP 0 583 006 A (MATSUSHITA ELECTRIC IND CO 
LTD) 16 fevrler 1994 (1994-02-16) 
colonne 3, Hgne 35 -colonne 7, Hgne 5 



1-27 



1,11 



1,11 



j j Voir la suite du cadre C pour la fin de la Itste des documents 



Les documents de families de brevets sont indiques en annexe 



a Categories speclales de documents cites: 

"A" document definlssant fetat general de la technique, non 

consider^ com me particulierement pertinent 
"E* document anterleur, mais publle a ta date de depot international 

ou apres cette date 

"L" document pouvant jeter un doute sur une revendication de 
priorite ou cite pour determiner la date de publication d'uno 
autre citation ou pour une raison specials (telle qu'lndlquee) 

n O u document se referant a une divulgation orale, a un usage, a 
- une exposition ou tous autre s moyens 

"P" document pub lid avant la date de depot International, mais 
post erieure men t a la date de priorite revendlqude 



document ulterieur publie apres la date de depot International ou la 
date de priorite et n'appartenenant pas a I'etat de la 
technique pertinent, mats cite pour comprendre le prlncipe 
ou la theorie constituent la base de r invention 



"X 



document particulierement pertinent; J'inven don revendiquee ne peut 
etre consfderee comme nouvetle ou comma impliquant une activite 
inventive par rapport au document considere tsolement 
"Y" document particulierement pertinent; I'inven tion revendiquee 

ne peut etre considered comme impliquant une activite inventive 
lorsque le document est assocle a un ou pluslaurs autre a 
documents de me me nature, cette combinaison etant evident e 
pour une personne du metier 
"&" document qui fait partie de la meme famitle de brevets 



Date a laquelle la recherche international a ete eft ectrvement achevee 



18 Janvier 2000 



Oate tf expedition du present rapport de recherche Internationale 



25/01/2000 



Nom et adresse postal© de I'admlnlstration chargee de ta recherche Internationale 
Office Europeen des Brevets, P.B. 5818 Patentlaan 2 
NL - 2280 HV Rijswljk 
Tel. (+31-70) 34CK2040, Tx. 31 651 epo nl, 
Fax: (431-70) 340-3016 



Fonctionnaire autorlse 



Goossens, A 
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Document brevet citd 




Date de 


Membre(s) de la 




Date de 


au rapport de recherche 




publication 


famille de brevets) 




publication 


US 5473690 


A 


05-12-1995 


FR 


2673476 


A 


04-09-1992 








DE 


69205425 


D 


16-11-1995 








DE 


69205425 


T 


?i -rn— 1 QQfi 

c.1 uj 1 jjO 








EP 


0589884 


A 


fiA— C\A— 1 004 








ES 


2082451 


T 
1 


id uoiyyo 








WO 


9213322 


A 


06-08-1992 








OP 


6504862 


T 


02-06-1994 


WO 9809257 


A 


05-03-1998 


US 


5923884 


A 
A 


lo-u/— iyyy 








AU 


4842897 


A 

A 


1 o_n 'J — 1 QQQ 

iy vjo iyyo 








CA 


2233217 


A 

A 


uo-u j j.yyo 








FP 


0858644 


A 

A 


1 0__n Q 1 QQQ 

iy-uo— iyy<5 


EP 0583006 


A 


16-02-1994 


JP 


2502894 


B 


29-05-1996 








JP 


6060235 


A 


04-03-1994 








JP 


6131517 


A 


13-05-1994 








DE 


69320900 


D 


15-10-1998 








DE 


69320900 


T 


28-01-1999 








KR 


9706648 


B 


29-04-1997 








US 


5408082 


A 


18-04-1995 
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